Package dependencies and package versions

If I understand things correctly: if I specify the sacha:foo package in my .meteor/packages file and the run meteor update, it will use the latest version of the package it finds on Atmosphere.

If I specify sacha:foo@0.1.0, it will use 0.2.0, 0.3.0, etc., but not 1.0.0.

But (again, please correct me if I got it wrong) if sacha:foo itself depends on sacha:bar@0.1.0, running meteor update will not update sacha:bar, even if sacha:bar@0.2.0 is available on Atmosphere.

The only way to get sacha:bar to update is to manually change it inside sacha:foo's package.js.

This can be a problem when publishing multiple packages that depend on each other (such as @slpendido’s useraccounts). It means that if you publish a new version of a dependency package, you also have to publish a new version of the packages that depend on it, otherwise the dependency won’t get updated.

So my question is: is there any way to force Meteor to update all packages – including dependencies – to the latest version?

Or alternatively, is there a way to specify a dependency on a package without pinning it down to a version? i.e. just write api.use("sacha:bar") instead of api.use("sacha:bar@0.1.0"), and just let Meteor use the latest version available?

4 Likes

I’ve never ever had a problem (yet) with a bleeding edge package and almost always wanted/needed to be on the latest either due to a bugfix or a shiny new feature. But I have been bitten many times by pinned down package versions and even had to fork some packages to update them manually. I, too, think api.use("sacha:bar") is much needed.

Some thoughts about this from @dgreensp:

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