Provide good messages when you provide invalid things to api.use and
api.imply.
Provide better message when you provide invalid things to
api.versionsFrom.
Drop "notInitialized" hack from catalog: now that we load things in
order, it's not necessary. (This means life will break if you use
api.versionsFrom in a uniloaded package. So don't do that.)
We now throw more specific errors, consistent between both tools and
package-version-parser (copy-and-pasted code, sadly, but we really do
have to make this check before uniload-from-checkout).
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.
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.
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'.
Leave around api.add_files so as to not break literally every
package. Leave our own uses of it alone until after merging to devel, so
that merging package.js files isn't a nightmare.
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"
