New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explain why package is top level #12928
base: release-3.0
Are you sure you want to change the base?
Conversation
There's some edge cases this won't show the correct message for. This needs more work and testing. |
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
packages point all to the latest dependencies. You can see the latest state in this PR |
You probably are publishing with Meteor 2.14, which uses The other possibility, less likely in this situation, is that the You can use |
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 |
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 oftop 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.