Previous discussion here.
My previous post on this topic: Package version numbers highly confusing
Maybe I’m in the minority, but Meteor’s package solver doesn’t make sense to me. Towards the end of my discussion with Sashko, he said:
In general, the version solver always picks the oldest set of packages that meet your constraints, so that you don’t accidentally get a newer version than what you are expecting
But by that logic, including version 5.0.0 of a certain package would simply ignore version 5.0.3, because it’s newer, and it would simply install 5.0.0. But in reality, when I required version 5.0.0 of
aldeed;autoform it actually did install 5.0.3. What I what actually expect is that requiring 5.0.0 would install 5.4.0, because the Meteor docs say:
In general, you must specify a package’s version (e.g., ‘email@example.com’ to use version 1.0.0 or a higher compatible version (ex: 1.0.1, 1.5.0, etc.) of the accounts package).
So which is it? When does the system look for a higher version, and when does it fall down to an older version? The documentation says if I include 1.0.0, it could possibly include 1.5.0, but my test disproved that (including 5.0.0 did not include 5.4.0).
I love pretty much everything about Meteor, but I think the package solver system falls short. Why can’t we use Node’s system, for instance? https://scotch.io/tutorials/node-and-npm-version-numbering-guide-and-best-practices