CODEWITHSUNDEEP
meteor
kctang
kctang

Reputation: 11202

Automatically update dependencies declared by local Meteor packages

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:[email protected]',
    'aldeed:[email protected]',
    'aldeed:[email protected]',
    'iron:[email protected]',
    'useraccounts:[email protected]'
]);

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.

Upvotes: 11

Views: 877

Answers (2)

MasterAM
MasterAM

Reputation: 16488

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).

Upvotes: 1

webdeb
webdeb

Reputation: 13211

This is from the docs:

In general, you must specify a package's version (e.g., '[email protected]' 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:[email protected] || =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.

Upvotes: 0

Related Questions