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 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.
This before was just an uncaught exception. Now it's exit(1), which is
bad too. This should just use buildmessage, but for some reason that
doesn't work here.
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.
Many of these (mostly in top level commands in commands-packages.js) are
not super well thought out: they use a new "doOrDie" helper to run some
function in a capture and exit if there are any messages. We really
need to get a little more thoughtful about the big picture of error
handling (combining "build" errors, network errors, catalog errors,
etc). But this at least allows the addition of more buildmessage
assertions.
At the very least, this ensures that if you edit a package.js in a local
package while "meteor run" is running, that instead of crashing the tool
it properly shows the buildmessage and lets you fix the issue.
Before, there were some random contexts (like 'test-packages') which
didn't print downloads. Now, the default is printing, and the exception
is the automatic background updater.
(Some of these bulk contexts should probably set silent and print their
own progress bar. And maybe even do paralellism...)
Generally clean up the tropohouse.maybeDownloadPackageForArchitectures
interface. Change it to take options, remove the vestigial return
value (though really, there needs to be better error handling...)
Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
Moving towards a world where all things that might invoke buildmessage.error are
encouraged to be in a buildmessage.capture.
This commit is the answer to the question "how many small changes need to be
made to add buildmessage.assertInCapture to PackageCache.loadPackageAtPath?"
Next steps include:
- Making catalog.resolveConstraints ALWAYS buildmessage.assertInCapture
(not just when ignoreProjectDeps isn't passed)
- Then changing resolveConstraints to complain using buildmessage
- Removing the process.exit(1) in _ensureDepsUpToDate
- Adding a more structured way to ensure that most commands
call _ensureDepsUpToDate at an unsurprising location
- in add, we actually do want to know the added version
- in remove, there's a distinction between truly dropping the package
and just dropping the top level constraint
specifically... for the bundling arch!
also, whenever running the project constraint solver, make sure
that (host) packages exist even if the versions haven't changed!
also fixes a bunch of other stuff like:
- parseStack markTop works again (so you get the right line numbers in
self-test)
- you can (with appropriate env var) run apps with NO PACKAGES at
all (even ctl)
- more consistently refer to METEOR-CORE@ releases as "Meteor 1.2.3"
