Why won't packages update without override?

I just noticed sometimes when I run meteor update, I get this message:

  • New versions of these packages are available! Run ‘meteor update’ to try to update those packages to their latest versions. If your packages cannot be updated further, try typing meteor add <package>@<newVersion> to see more information.

But some packages will automatically update when meteor update is run. Why are packages being held back from updating?

And as a package author, how do you set a stopping point where a user has to manually use meteor add <package>@<version> to update?

Some packages will have dependencies on other packages. In order to avoid future breakage of the dependant package, the developer will sometimes lock a dependency to a particular version.

The Meteor build chain currently allows only one instance of a package’s code, so the dependency resolver will look for the best version compatible with every dependant. Clearly, this may be at an earlier version than the latest.

I had a situation where I was using @manuel’s viewmodel package, I think at 1.7.6, and running meteor update wouldn’t update it to 1.8.1 which was an important performance update. So I had to do meteor add manuel:viewmodel@1.8.1. Hopefully this won’t cause any issues.

Related question: packages that won’t update via meteor update, will they eventually update at some point later once the dev unlocks it?

And finally… how does a package developer pin/lock and unlock a version?

I’ve never tested that, but it should update once the version pinning is removed/changed.

Check the docs here

I had a (quite) similar problem, for some time, all the new packages i was installing were installed at version 0.0.1, i had to manually force them at their latest version.

ViewModel doesn’t lock versions. Do a meteor reset an if the problem persists post the results of meteor list

Strange, it was stuck at 1.7.6. I already manually updated all my packages, but if it happens again, I’ll try your suggestions.

I think the point is that some other package you’re using has a pinned dependency on viewmodel (not the other way round).

Ah of course. That’s strange. I installed viewmodel myself, so nothing else was depending on it. Could’ve just been a glitch.