It is rather tedious when trying to get dependencies of local Meteor packages up-to-date.
Currently, they are specified in package.js like and I have to check for latest version of each dependency used and update manually.
E.g.
api.use([
'alanning:roles#1.2.14',
'aldeed:simple-schema#1.5.3',
'aldeed:collection2#2.8.0',
'iron:router#1.0.12',
'useraccounts:iron-routing#1.12.4'
]);
Can meteor-tool do this or is there a better way to update packages' dependencies, especially useful when you have multiple local packages in a project.
There is no real value in bumping the dependency version in package.js, as I mentioned in my comment. It could lead to the counter effect and break version resolution.
The expectation is to mention the minimal compatible version (with the same major version number). When your local package is updated, its .versions file is updated as well, which may hint the build system which version of the dependency is the preferred one to use (the one that your package was built with).
The closest thing that I can give as an answer is this quote of David Greenspan* taken from the Meteor forums:
We have made some small improvements to meteor update over time, but
we don't have a way for a package to ask for one of its dependencies
to be upgraded more aggressively. meteor update with no arguments will
take patch updates to indirect dependencies, but not minor versions. I
recently improved the messages that meteor update prints, so in the
next release, it should tell you if an indirect dependency is not at
the latest version after it runs (rather than printing the very wrong
message "All packages are at their latest compatible versions").
If you bump the minor version of a package, I think the expectation at
the moment is that you will republish the packages that depend on it
if you want their users to get the new version (after running the
tests to make sure all is well).
So, when the author of a package you depend on releases a new:
patch version: no need for you to do anything. The new version should be used automatically.
minor version: check that everything works and release a new patch version, as to acknowledge the new version.
major version: things are expected to break. Make the required changes and release according to semver rules.
I would not count on things behaving as they do right now, as the packaging system undergoes pretty significant rework in order to be more compatible with NPM (including the ability to directly require NPM packages from Meteor apps and packages), expected to be included in v1.3.
* (actually, Sacha Greif posted the quote).
This is from the docs:
In general, you must specify a package's version (e.g.,
'accounts#1.0.0' to use version 1.0.0 or a higher compatible version
(ex: 1.0.1, 1.5.0, etc.) of the accounts package). If you are sourcing
core packages from a Meteor release with versionsFrom, you may leave
off version names for core packages. You may also specify constraints,
such as my:forms#=1.0.0 (this package demands my:forms at 1.0.0
exactly), or my:forms#1.0.0 || =2.0.1 (my:forms at 1.x.y, or exactly
2.0.1).
So the answer is, it will not update your package.js script but it will download the latest compatible versions, depend on your settings.
Related
I need to get acquainted specifically with elm 0.16.XX because some project I am working on is using it, and long story short,e.g. the version cannot be changed. Also, as you guys know there is a significant change between 0.16 and later elm versions. I am doing an online video course that has the 0.16.XX version but when I install elm, it naturally installs the latest version. How can I install the older versions?
The info I see online says to just change in elm.json, the version numbers of dependencies you need, but the problem is that the names of the dependencies have also changed. e.g in a basic hello world project,
0.16.xx
"elm-lang/core": 5.1.1, "elm-lang/html": 2.0.0, "elm-lang/virtual dom": 2.0.4
as opposed to modern elm
"elm/core": 1.0.5, "elm/html": 1.0.0, "elm/virtual-dom": 1.0.3
So how do I go about installing older elm i.e 0.16.XX. Any help is appreciated.
In theory, you could download the source code zip and try to build from sources but I remember people having a lot of trouble with the particular Haskell dependencies.
If the app is an Html based app that used evancz/start-app you might have some luck by first upgrading to 0.17.1. Take a look at https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md
You might be able to install 0.17.1 with npm i -D elm#0.17.1.
elm.json is available only to 0.19 and 0.19.1 projects. The versions before that used elm-package.json
You can download Elm 0.16 installers for Windows and Mac Elm from the official releases.
https://github.com/elm/compiler/releases/tag/0.16.0
But I have no idea if installing the dependencies still works.
So maybe you'll need to incrementally upgrade your code, see https://github.com/elm-lang/elm-platform/tree/master/upgrade-docs
If that is too complicated, maybe you can ask in the Elm slack if someone can upgrade the code for you? E.g. with a small freelancer contract?
I have configured Julia portable or standalone according to the link:Julia portable or standalone
But I want to update to the latest version of Julia 1.5.1.
How to proceed?
Should I add all the packages again?
Is there a way to import it to the new version?
Julia does not support version upgrade. It perhaps might work for some packages but you are always risking to running into issues.
Hence you need to delete the .julia folder (or set a new JULIA_DEPOT_PATH location which is configured by system variable) and just reinstall all the packages.
However if you for some reason strongly want to reuse the .julia folder you can try:
https://discourse.julialang.org/t/a-proper-introduction-on-how-to-update-julia-somewhere-accessible/28166
I am configuring semantic versioning with GitLab for my dotnet core apps and netstandard 2.0 packages.
After reading quite a bit of opinions, some of them contradictory, this is what is clear to me.
A semantic version should be something like
M.m.P.B-abc123 where
M is major version
m is minor version
P is patch version
B is build version (optional)
-abc123 is suffix (optional) in case I use pre-releases. It must start with letter
So the following package versions would be valid:
1.0.0
1.0.1.20190301123
1.0.1.20190301123-beta
1.0.1-rc1
I have the following gitlab script for my versioning
#Stages
stages:
- ci
- pack
#Global variables
variables:
GITLAB_RUNNER_DOTNET_CORE: mcr.microsoft.com/dotnet/core/sdk:2.2
NUGET_REPOSITORY: $NEXUS_NUGET_REPOSITORY
NUGET_API_KEY: $NEXUS_API_KEY
NUGET_FOLDER_NAME: nupkgs
#Docker image
image: $GITLAB_RUNNER_DOTNET_CORE
#Jobs
ci:
stage: ci
script:
- dotnet restore --no-cache --force
- dotnet build --configuration Release
- dotnet vstest *Tests/bin/Release/**/*Tests.dll
pack-beta-nuget:
stage: pack
script:
- export VERSION_SUFFIX=beta$CI_PIPELINE_ID
- dotnet pack *.sln --configuration Release --output $NUGET_FOLDER_NAME --version-suffix $VERSION_SUFFIX --include-symbols
- dotnet nuget push **/*.nupkg --api-key $NUGET_API_KEY --source $NUGET_REPOSITORY
except:
- master
pack-nuget:
stage: pack
script:
- dotnet restore
- dotnet pack *.sln --configuration Release --output $NUGET_FOLDER_NAME
- dotnet nuget push **/*.nupkg --api-key $NUGET_API_KEY --source $NUGET_REPOSITORY
only:
- master
This generates packages such as:
1.0.0 for master branch (stable or production ready) and 1.0.0-beta1234567 for any other branch.
The problem with my approach is that I have VS solutions with multiple projects, each project will be a nuget package and each one has its own version. Sometimes I modify one project but not the other, therefore in theory I shouldn't need to produce a new artifact of the project that I didn't touch nor a new version, of course.
Right now my nuget repository prevents overwriting packages, so If there is a XXX.YYY 1.0.0 and I generate another XXX.YYY 1.0.0 and push it to the repository, it will throw an error and the pipeline will fail.
I have thought that maybe it's not such a bad idea to generate a new package each time I run the CI/CD pipeline, so I considered introducing the build number and have something like XXX.YYY 1.0.0.12345 and, even if I don't touch anything there, the next time a new package XXX.YYY 1.0.0.123499 would be produced.
Is this a correct approach in a continuous deployment scenario? or should I look for a way to make my script smarter and not to produce a new artifact if there is already one with the same version in my nuget repository?
Assuming it's ok to use build numbers always, how do I make sure that only the build number is retrieved from the pipeline but the M.m.P version numbers remain in my csproj as per the following?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<Description>Whatever</Description>
<VersionPrefix>1.0.1</VersionPrefix>
</PropertyGroup>
</Project>
I would need something like:
dotnet pack *.sln --configuration Release -p:PackageVersion=$FIXED_VERSION.$CI_PIPELINE_ID --output nupkg
but I don't know how to retrieve the <VersionPrefix> content from the csproj through the CLI.
Any advice, good read or solution for my approach assuming it's valid?
Thanks
The problem with my approach is that I have VS solutions with multiple projects, each project will be a nuget package and each one has its own version. Sometimes I modify one project but not the other, therefore in theory I shouldn't need to produce a new artifact of the project that I didn't touch nor a new version, of course.
Since a continuous integration pipeline is unable to determine if your code should be a new minor or major version you will always have to determine which semantic version your package should get. This makes the whole process a lot easier.
The guys from visual studio team services have this to say about it:
Immutability and unique version numbers
In NuGet, a particular package is identified by its name and version number. Once you publish a package at a particular version, you can never change its contents. But when you’re producing a CI package, you can’t know whether it will be version 1.2.3 or just a step along the way towards 1.2.3. You don’t want to burn the 1.2.3 version number on a package that still needs a few bug fixes.
SemVer to the rescue! In addition to Major.Minor.Patch, SemVer provides for a prerelease label. Prerelease labels are a “-” followed by whatever letters and numbers you want. Version 1.0.0-alpha, 1.0.0-beta, and 1.0.0-foo12345 are all prerelease versions of 1.0.0. Even better, SemVer specifies that when you sort by version number, those prerelease versions fit exactly where you’d expect: 0.99.999 < 1.0.0-alpha < 1.0.0 < 1.0.1-beta.
Xavier’s blog post describes “hijacking” the prerelease tag to use for CI. We don’t think it’s hijacking, though. This is exactly what we do on Visual Studio Team Services to create our CI packages. We’ll overcome the paradox by picking a version number, then producing prereleases of that version. Does it matter that we leave a prerelease tag in the version number? For most use cases, not really. If you’re pinning to a specific version number of a dependent package, there will be no impact, and if you use floating version ranges with project.json, it will mean a small change to the version range you specify.
Source: https://devblogs.microsoft.com/devops/versioning-nuget-packages-cd-1/
As stated first you still need to pick a version yourself for you new package. For the process before the actual publishing of the final package (master branch in your case) you can use the pre release tag to include the build number as the pre release tag.
Without doing anything smart this will publish a new package for every pipeline that is run. The people at visual studio team services and I do not think that this is a bad thing but this will be up to everyone's personal taste
I know it's a little bit late, but maybe others in the future also ask this question.
For background: I work in a small company and we started in the NodeJS world with NPM packages. After a while we also started building with .NET Core and we kind of adapted some things from the JavaScript world. A tool we used heavily is Semantic Release. It automates versioning by parsing commit messages. So you (and everyone developing on the project) use a special format for commits with a prefix type like fix, feat, chore and so on, and Semantic Release parses every commit message since the last release and determines the next version number.
Since in JS world you have to only update the package.json file it kinda works out of the box but for .NET there is a little bit more work to do.
We use the Directory.Build.props file to set the version like you would do with package.json (but it would work in a csproj file too).
Now Semantic Release works with plugins and one plugin we wrote can update files with the version number. So we use it to update the verson number in Directory.Build.Props. But instead of the version in the file you could also directly give the version number to the dotnet nuget cli but we found it more convenient to have it in the file.
So here's the flow we use for our (internal) NuGet packages:
configure Semantic Release to update the version number in Directory.Build.props file (before creating the package)
create the nuget package (we have another plugin for that, but you could just use the exec plugin during the prepare stage of SR
publish the nuget package during the publish stage of SR
The CI script would then just a call to npx semantic-release in an environment that has NPM as well as the .NET SDK available (we use container images for that).
Especially for OP's situation it would be a little bit more complicated, since multiple projects exists in one repository and SR is made to work in a single repository since it works with git tags to determine the last version. So I would advise to split it in multiple repositories.
The benefits are:
automation of release whenever there is a new feature/bugfix
automation of version numbers that adhere to Semantic Versioning (and is unopinionated)
automatically generate a Changelog along with every release
depending on the Git Platform you can also create releases (there are plugins for GitHub, GitLab and others)
you can configure SR to create pre-releases in certain branches, for example you can have an alpha or beta or develop branch
you could also add the commit hash to the NuGet package so everyone using it would know exactly what is bundled in it
Semantic Release creates a commit with the updated package.json (you can configure it to also include the updated Directory.Build.props and I would advise to do so)
And all you have to do is to configure it one time and enforce a special Commit Message style (which one is not so important, you can configure SR accordingly).
I am new to meteor, I was trying to use file upload using
tomitrescak/meteor-uploads
I successfully uploaded some file, but when I tried to delete the uploaded file, I got error in my terminal Reference Error:check is not defined
I have checked the documentation and searched the web regarding this error but could not find any solution for this.
Note: I got similar error while studing http://meteortips.com/second-meteor-tutorial/iron-router-part-1/
OS: Ubuntu 14.04
meteor: 1.2.1
TL;DR
$ meteor add check
Longer version
In Meteor version prior to v1.2, a core package called meteor-platform used to export some symbols, including check.
Since v1.2, this is no longer the case and those symbols are no longer available via the platform, but using dedicated packages instead.
It is likely that one of the packages that you are using (or your app code itself) is using check (probably in one of its methods) without declaring it as a dependency.
Until the package maintainers update the dependency, you should be able to overcome the error by adding check as a top-level dependency:
$ meteor add check
If you identify which package is causing the issue, you can report it on GitHub, or fork the package yourself, add the missing dependencies and submit a pull-request.
How do I find out what is holding my app up from updating? I keep getting the 'This project is at the latest release which is compatible with your current package constraints.' message.
Here is the output from the update command:
Refreshing package metadata. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
This project is at the latest release which is compatible with your
current package constraints.
My packages.js looks like so:
# Meteor packages used by this project, one per line.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.
accounts-base
accounts-password
alanning:roles#=1.2.9
arunoda:npm#0.2.6
ch-activity
ch-activityreport
ch-arrestreport
ch-assetreport
ch-citation
ch-fieldinterviewreport
ch-incidentreport
ch-inspectionreport
ch-location
ch-media
ch-narrative
ch-organization
ch-person
ch-property
ch-signature
ch-vehicle
cmather:iron-router#0.8.2
coffeescript
copleykj:mesosphere#0.1.9
d3
dash-patrol
email
less
mizzao:bootboxjs#4.2.1-master.1
mrt:accounts-ui-bootstrap-3#=0.3.3
mrt:leaflet#0.3.8
mrt:mongo-counter#1.1.0
notices
sacha:spin#2.0.4
standard-app-packages
tsega:bootstrap3-datetimepicker#=0.2.0
I have migrated all the ch-* and dash-* packages to the new format. Those are local, in app, packages. Those cannot be in public repositories.
Try replacing
cmather:iron-router#0.8.2
with
iron:router#0.9.1
in your packages file.
I'm think it may be because not all your packages are compatible with Meteor 0.9.0
If you want to check what packages are currently compatible enter this code:
meteor search (Package Name)
By default meteor will only return compatible packages, so you can find which packages aren't working by searching each one. If you can't find the package, then its probably not compatible and you aren't going to be able to run the latest version of Meteor unless you remove it.
Don't worry though! While Meteor 0.9.0 is quite buggy, they are working hard to update all the packages and patch the bugs. Just give it a few weeks to sort itself out if that doesn't work :)
Best Of Luck! Hope This Helped!
Meteor search is included in the latest release. Docs: http://docs.meteor.com/#meteorsearch
Try running this command and you should be able to access meteor search
meteor update
Also, the update should tell you if there's a package update available, although I had to run update (packagename) on each starred package for it to update
meteor update aldeed:collection2
I found that I had to remove my ~/.npm directory and run meteor again to resolve some npm dependencies I had. Perhaps you have some npm dependencies as well?