Summary: Also update the skeleton app to use meteor-platform
Test Plan: Created a new app, it had meteor-platform, it ran
Reviewers: dgreenspan
Reviewed By: dgreenspan
CC: avital, emily, nim
Differential Revision: https://phabricator.meteor.com/D785
Not sure what the original motivation for printing <unknown> was (it
shouldn't ever come up in normal operation, only if something weird
happens like we manually unset a user's username in the database). But
it's now rather inconvenient because we don't yet clean up deleted
organizations from a site, so you would see <unknown> for every
authorized organization that has been deleted. While we should
eventually clean up deleted organizations from a site's
"authorized_orgs" field, for now this will clean up the output of this
command.
Replace catalog.getLatestVersion with catalog.getLatestMainlineVersion,
which skips prerelease versions (those with dashes in the
version). Ensure that this function is only used by high-level commands
like 'meteor list'. Replace other uses of that function with other
equivalent functions.
Also, don't stack trace on 'meteor add' constraint failure.
Before, we were running the constraint solver with both the new and the
old constraint, which would fail if they were not simultaneously
satisfiable. (We were writing the right thing to disk if it succeeded,
at least.)
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.
The idea is that dotfiles in .meteor (like .id and .finished-upgraders)
aren't intended to be human-editable, whereas packages, release,
and versions are (although there are commands to edit them too).
Make sure 'meteor add foo' gives the same constraint to the solver as
'foo' from .meteor/packages: namely, '>=0.0.0' not
'unconstrained' (since the first rules out rcs and the second doesn't)
Make sure that project._ensureDepsUpToDate does not get run mid-update,
since it might decide that various things are not compatible with the
packages in the current release. When the update command runs the
constraint solver explicitly, it passes ignoreProjectDeps, but implicit
calls can lead to an unhappy process.exit.
We were accidentally considering this equivalent to 'meteor update
--release LATEST', meaning we could not update to an intermediate
release (and that it could update you backwards).
