Hello all,
I've rewritten Meteor's version constraint solver to be faster and
more predictable, using real constraint satisfaction algorithms. I'd
like you to try this new preview release and report any issues you
come across, using one of the following commands:
meteor --release METEOR@new-version-solver-2 # one-off
meteor update --release METEOR@new-version-solver-2 # sticky
The version solver is what decides which other packages to add,
remove, upgrade, or downgrade automatically when you add, remove, or
update a package in your app. It's an often-invisible but crucial
part of the Meteor experience. The old solver served us well, but it
would occasionally take a very long time to run, and it used heuristic
methods so it was difficult to reason about.
In one test of the new solver, a case that previously took 20 seconds
now takes around 1.5 seconds, and furthermore it finds a globally
optimal solution. There is some further optimization to do to bring
down the constant factors, so you may actually find that the
"Selecting package versions" sometimes takes *longer* now with this
release. That will be ironed out with subsequent preview releases.
In the mean time, it would be extremely helpful for you to try the new
solver before it is released. (And if you run into a very slow case --
defined as more than a few seconds -- we can now turn it into a
reproducible benchmark.)
There are some new features, too!
* Better error messages when you have conflicts or an "unknown
package". We now show more information about what the constraints
are and where they come from.
* Meteor will never upgrade or downgrade your top-level dependencies
to semver-incompatible versions. For example, adding a package
won't downgrade an existing top-level package by a minor version.
Or, if a local package is found to be older than the expected
version as recorded in .meteor/versions, you'll get an error. To
override this behavior and make breaking changes to your package
versions, pass the new command-line switch `--breaking`.
* Fixes issue #3653: "Downgrading packages for no reason". This bug
occurs when checking out and running a Meteor app on a new machine.
Meteor would downgrade a package if it hadn't heard of the version
in .meteor/versions. Now this case will trigger a catalog refresh.
* The new cost function will choose "patched" versions of packages in
some cases where it would previously choose older versions. For
example, if you add package A to your app, and package A uses
package B...@1.0.0, the solver will consider versions of B like 1.0.1
and 1.0.0_1 to be good initial versions for B. After that, the
behavior is the same as before, namely, the version of B will
generally remain constant until a different version is asked for by
a newer version of A or by another package, or you run `meteor
update B`.
Thanks for reading, and I look forward to your feedback and to making
a few performance tweaks before releasing the new solver.
-- David