Would love to see Meteor's package solver given an overhaul

core
1

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

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

Thoughts?

2

It’s possible that some other constraints on the versions meant that 5.0.0 wasn’t possible to use.

3

I’d also like to repost the link to the “Packaging UX: Gravity Hurts” hackpad about this issue: https://meteor.hackpad.com/Packaging-UX-Gravity-Hurts-FoTnLTVUklt

4

But I’d like to have more transparency into that when I use meteor add or meteor update, or api.use. Meteor doesn’t give enough feedback when it’s picking a version, and if it decides to skip one or not do what I think it should’ve done, a detailed message would be nice (“using x.y.z because of constraint with…etc”).

Node’s versioning system makes sense to me. It’s practical, it has a set syntax that is clearly defined, and it’s very predictable. By contrast, Meteor’s is unpredictable and nebulous, IMO.

I’d also like to point out that I’ve seen some pretty major packages on Atmosphere behave problematically because I’m assuming the devs didn’t have a complete understanding of how version dependencies work. What I’m saying is that I can’t be the only person to find it confusing. :smile:

1 Like
5

And just to be clear… (because sometimes I’m uncomfortable criticizing open source) everything else about Meteor is amazing, and it’s one of the best things in tech that I’ve discovered, ever. :grin: I’m just offering up feedback to anyone who finds it useful. If, at the end of the day, we can improve the framework, I think that’s a win.

6

Haha I’m totally with you, and criticizing things constructively is a good thing to do!

One good thing is that some recent overhauls in the version solver have made it a lot easier to display good errors about this stuff, we just haven’t gotten there yet. We did all of the hard work, but none of the “easy” work about printing good messages and having good defaults.

1 Like