Incorrect version of packages being picked


#1

Adding a package using meter add is picking latest version correctly, but adding the same package inside another package with api.use() picks very old version.

For example,
meteor add aldeed:tabular resulted in aldeed:tabular added, version 1.1.0
where as
api.use(["aldeed:tabular"], "client"); picked up version 0.1.0

api.use() should also pick the latest version when none specified, just like meteor add.


Incorrect version of alanning:roles getting installed from external package
#2

The goal here is that we can determine which versions of a dependency your package works with just by looking at the api.use declaration. If you don’t specify the version of a dependency inside your package.js but expect that version to be included, someone using your package might run into a problem when they try to manually add some different version.

Basically, for the constraint solver to correctly identify the versions of dependencies when multiple packages have the same dependency with different versions, you need to specify what version your package works with.

Why not just put "aldeed:tabular@1.1.0" if that is the version you want?


#3

Thanks you @sashko

If I specify “aldeed:tabular@1.1.0” does it automatically update when new version avilable, like when ‘meteor update’ ?

I like your point:

I agree that package developer should specify what version his packages works with - only point I am trying to put forth is - “If I do not specify the version, assume that I want the latest version. and not the oldest version”.

The design choice that "package developers want the oldest version" when they do not specify the version while "meter add" users want the latest version" - is not justified enough.

Package developer should get the same benifit as end user developer


#4

From the docs, yes they will if the package ensure backward compatibility:

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


#5

Thanks @yuukan

Any info on how this backward compatibility is determined? Some kind of markup inside package.js?

Because looks like “aldeed:tabular” when used from inside a package (through api.use()) is not automatically picking the latest version - and wondering which part of the code inside aldeed:tabular is prohibiting it. Also, would be useful while developing own packages to ensure they are backward compatible.

On a side note though, it would be ideal for api.use to have same version picking behavior as meteor add. Explicitly asking to run meteor update every time a new api.use line added inside package.js is not so dev-friendly (given that meteor add does not demand it).