When publishing a core package, you’re allowed to omit version numbers in package.js. With this change, we determine the correct versions of all the dependent packages based on the current checkout, and we send them to troposphere (instead of core packages having “null” constraints on their dependencies).
We throw an error if you have any missing version constraints on your package dependencies and you are not using versionsFrom or publishing a core package from a checkout.
We’ve already fixed this (no constraints on core package deps) retroactively in troposphere.
It speeds up the constraint solver by orders of magnitude when publishing a package.
This allows us to later increase the pool for well-formed versions without requiring
moving the catalog's data.json into a new folder, which would require re-syncing
the entire catalog.
Previously, if we were asking for a pre-release, we would only return true if it was the
same pre-release, or at least on the same release. But that's not true. 1.2.4 should be valid
if we want 1.2.4-rc0, for example, and, even 1.2.3-rc0. (I mean, if it has the same ecv, which
it might not). This is also what was causing some of the issues around 0.9.1 rollout, we think. So,
we are going to try treating rcs like normal versions as far as comparisons go. We still don't want to
give you an rc unless you asked for it though.
Most people think of package deps in terms of packages, not unibuilds,
but our constraint solver has all these generated "if you're using
foo#os@1.0.0, use foo#web.browser@=1.0.0" constraints. They are just
distracting in errors (which already hide the unibuild part for
clarity) so make sure we don't see them in paths either.
(I could imagine a flag/env var that skips all the removeUnibuild calls
and this special processing, for "gory details" mode.)
Note that we now avoid adding usedRCs:undefined to the resolver return
value, since that makes tests annoying (especially since our display
drops undefined, ah well).
Drop the "at-least" constraint type entirely. It was not user-accessible
and was only used in the form ">=0.0.0" to represent a constraint with
no version constraint at all. This type of constraint is now called
"any-reasonable".
The definition of "any-reasonable" is:
- Any version that is not a pre-release (has no dash)
- Or a pre-release version that is explicitly mentioned in a TOP-LEVEL
constraint passed to the constraint solver
For example, constraints from .meteor/packages, constraints from the
release, and constraints from the command line of "meteor add" end up
being top-level.
Why only top-level-constrained pre-release versions, and not versions we
find explicitly desired by some other desired version while walking the
graph?
The constraint solver assumes that adding a constraint to the resolver
state can't make previously impossible choices now possible. If
pre-releases mentioned anywhere worked, then applying the constraints
"any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
ruled first impossible and then possible again. That's no good, so we
have to fix the meaning based on something at the start. (We could try
to apply our prerelease-avoidance tactics solely in the cost functions,
but then it becomes a much less strict rule.)
At the very least, this change should allow you to run meteor on a
preview branch like cordova-hcp without getting a conflict between the
prerelease package on the branch/release and the lack of an explicit
constraint in .meteor/packages on that package, because we are
reintepreting the .meteor/packages constraint as meaning "anything
reasonable" and the in-the-release version counts as reasonable.
