Explain why package is top level

[zodern]

When there are conflicts in the version constraints for a package, Meteor lists all of the constraints along with the path. Sometimes the path is simply top level. The meaning of top level doesn't seem to be common knowledge anymore (if it ever was), so this PR adds an explanation for why the package is top level (it is either a local package, or the constraint is from the release).

I haven't tested the code for top level packages from a release since when running Meteor locally every core package is a local package. I thought the meteor-tool might have a way to test this, but I didn't find one.

=> Errors while adding packages:             
                                              
While selecting package versions:
error: Conflict: Constraint [email protected] is not satisfied by caching-html-compiler 1.2.1.
Constraints on package "caching-html-compiler":
* caching-html-compiler@=1.2.1 <- top level (is local package)
* [email protected] <- static-html 1.3.3-alpha300.19

Conflict: Constraint [email protected] is not satisfied by templating-tools 1.2.2.
Constraints on package "templating-tools":
* templating-tools@=1.2.2 <- top level (is local package)
* [email protected] <- static-html 1.3.3-alpha300.19
* [email protected] <- caching-html-compiler 1.2.1 <- static-html 1.3.3-alpha300.19

Conflict: Constraint [email protected] is not satisfied by caching-compiler 2.0.0-alpha300.19.
Constraints on package "caching-compiler":
* caching-compiler@=2.0.0-alpha300.19 <- top level (is local package)
* [email protected] <- caching-html-compiler 1.2.1 <- static-html 1.3.3-alpha300.19

[zodern]

There's some edge cases this won't show the correct message for. This needs more work and testing.

[jankapunkt]

How is top-level defined, when being in a package (no .versions file present in folder; no Meteor project in parent folder)?

I currently can't publish a migrated package, which runs locally in a Meteor 3.0-beta.0 project fine but when publishing I get issues with "top level":

error output

=> Errors while initializing project:         
                                              
While selecting package versions:
error: Conflict: Constraint [email protected] is not satisfied by mongo 1.16.8.
Constraints on package "mongo":
* mongo@~1.16.8 <- top level
* [email protected] <- lai:collection-extensions 1.0.0-beta300.0
* [email protected] || 1.12.0 || 2.0.0-beta300.0 <- aldeed:collection2 4.0.0-beta.7 <- local-test:lai:collection-extensions
1.0.0-beta300.0
* [email protected] <- accounts-base 2.2.9 <- lai:collection-extensions 1.0.0-beta300.0
* [email protected] <- dburles:mongo-collection-instances 1.0.0-beta300.0 <- local-test:lai:collection-extensions
1.0.0-beta300.0

Conflict: Constraint [email protected] is not satisfied by accounts-base 2.2.9.
Constraints on package "accounts-base":
* accounts-base@~2.2.9 <- top level
* [email protected] <- lai:collection-extensions 1.0.0-beta300.0
* [email protected] <- local-test:lai:collection-extensions 1.0.0-beta300.0

packages point all to the latest dependencies. You can see the latest state in this PR

[zodern]

You probably are publishing with Meteor 2.14, which uses [email protected]. You can check this by running meteor --version to see what version is being used, and then meteor show [email protected] to see what the constraints are. The uppercase METEOR is for viewing the meteor release track instead of the meteor package.

The other possibility, less likely in this situation, is that the METEOR_PACKAGE_DIRS env var points to a folder that has a local copy of version 1.16.8 of the mongo package

You can use meteor publish --release 3.0-beta.0 to publish with Meteor 3.

[jankapunkt]

Thank you, it worked! I assumed that it was due to the 2.14 release being pinned globally, which is why I was asking on the forums how to make the global Meteor point to 3.0, which I couldn't work out but I didn't know that I can pin a specific release for publishing, since--release is not documented when typing meteor publish --help.