This means that we won't have to bump the version number of every
npm-using package every time we do a patch update of Node. (Though we
will have to do it right now, once.) (That's because the .node_version
file is part of the package's contents... which is semantically
correct.)
This resolves#2403. Specifically, if you implement some form of
two-way databinding, and you modify an input field in some way
other than adding characters to the end, the insertion point
jumps to the end.
Still need to write a test for this.
The point of the other catalogs is to allow local packages to override
server packages. This has nothing to do with releases. So rather than
keep release metadata in memory multiple times and force developers to
wonder "what's the different between catalog.complete.getReleaseTrack
and catalog.official.getReleaseTrack?", now it really just only exists
on catalog.official.
This should be a performance win (no need to load constraint-solver
unless you actually need to use it!), and it's what I wanted to do
initially instead of lazily loading mori, but it wasn't feasible with
the old super-recursive catalog.
This fixes an issue where running 'curmeteor rebuild' twice (!) died the
second time with a "Can't load npm module 'mori'" error. This is because
uniload (when run from a checkout) sets up Npm.require to read directly
from PACKAGE/.build.PACKAGE/npm/node_modules, which might get deleted
later in the process! There are some complex and maybe slow ways to
resolve this general issue (copy the node_modules somewhere else?) but
for now, the easiest way to avoid the issue is just to load Npm modules
immediately inside packages which need to be uniloaded.
- The checkout catalog.uniload now does not uniload a resolver, and
instead just has a trivial implementation of resolveConstraints.
(The 'built' catalog.uniload already didn't use the resolver.)
- catalog.complete.resolveConstraints now throws an error if there's
no resolver; this is OK, because creating the resolver now only
uses the distinct catalog.uniload, so there's no recursion issue.
- don't record version dependencies in packages during uniload (this
protects against using release.current before it is initialized)
- PackageLoader should never download packages during uniload (this
protects against using catalog.uniload.isLocalPackage before it is
initialized)
Actually verify that uniloaded packages are in the list. Add missing
'ejson'. Remove (ah well) test that relies on ability to uniload an app
package (which shouldn't work anyway, but it would be nice to test
uniload Assets...)
We're going to make uniload use a different flavor of "complete" catalog
soon. So we need to reduce the number of singleton-ish references to
it.
Also, we need one PackageCache per catalog, so stop it from being a
singleton too.
Also eliminated arguments that weren't used anywhere,
and removed an XXX comment that was false (recordPackages
doesn't use buildmessage to report connection failures)
