It looks wrong to see `Deploying to http://foo` without the
meteor.com. (The "Now serving" message gets the full site name from the
server and is fine.)
Original commit was from #2770.
As far as I understand, cordovaDependencies exist in these places:
- On an entire package (not an individual unibuild), as stored in the
main JSON blob (isopack.json)
- On a target (combination of many packages), as stored in the star
This commit removes some stray code where they show up in other places:
- A field (which is never written) is read from the individual unibuild
JSON file and passed to the Unibuild constructor, which does not
expect it.
- A field (which is never read) is written to the buildinfo.json file.
Also, an assignment to Isopack.cordovaDependencies is pulled out of a
loop.
This was an undocumented and entirely unused feature (only two dummy
packages on the package server have this set to a non-default value).
No attempt is being made to remove the field from existing isopacks or
catalog entries. To continue to support existing clients, the package
server has been modified to ignore any provided
earliestCompatibleVersion and instead always write the default ECV to
the catalog.
Neither read from them nor write to them.
Yes, this means that when running from a checkout, rebuilding an
isopacket (eg because you modified ddp or something) is a little
slower. But it's more correct --- having a single cache in the source
tree that's shared between apps (which run in catalog.complete mode) and
isopackets has some serious correctness issues. And the common case
where no isopackets have to be rebuilt is still fast (./meteor --version
takes about 0.24 seconds).
There is no longer a uniload catalog when running from a release, since
the release contains whole isopackets (programs) not
isopacks (packages).
We only need a uniload-specific catalog when we're actually rebuilding
isopackets (not in order to load them), so we now have it as a local
variable in the two places that build isopackets.
The deleted code in package-loader.js was specific to the prebuilt
uniload package which no longer exists.
You can only request a named set of packages, not a random assortment.
In future commits, we will pre-build these packages into JsImages and
load them from that. Building packages for uniload will eventually not
involve the .build.foo directories at all. (All saved packages will be
built in app context, eventually.)
An Isopack object can be created in one of two ways: by parsing a built
isopack from disk, or by compiling a PackageSource (which may or may not
get written to disk).
In the former case, its nodeModulesPath field will be something like
"npm/node_modules", referring to the node_modules directory inside the
built isopack, which has already had Npm.strip applied to it.
In the latter case, its nodeModulesPath field is actually the
pre-stripped node modules directory (eg '.npm/package/node_modules'). So
if we were to use such an Isopack object inside a bundler operation, we
would need to actually apply the strip operation at bundle time.
As far as I can tell it may not actually be possible to trigger this bug
yet, because for some reason we never quite seem to use the built
Isopack in bundler without cycling it through disk. But I've managed to
trigger it on the isopackets branch, and it's certainly a goal to use
our in-memory caches better (and not require unnecessary write/read
cycles).
Should be basically backwards compatible (they both join on spaces) but
has the following advantages:
- Objects are printed with util.inspect rather than toString, which
means no more [object Object]. (We shouldn't be passing objects to
end-user messages, but they can be useful in Console.debug.)
- The first string can optionally be a printf-style format string, if
that's a better fit for your message.
unnecessary: because dontRunConstraintSolver now means we don't need to
be in a buildmessage.capture
dangerous: because if you don't check the result of
buildmessage.capture, you leak errors.
