If we don't clean up the tarball, then the following command (`meteor
build`) fails ("Couldn't create tarball"), but for some reason still
exits with code 0. So we then go on to successfully untar the output of
`meteor build`. If we clean up the tarball from `meteor bundle`, we at
least catch the failure by trying to untar a nonexistent file.
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.
(Should these files really be checked in? With tools/tests/apps, the
apps are always copied into a temp directory before running meteor,
which is better.)
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
symlink as a special case for runner only
future commits on this branch will add a
package.json/npm-shrinkwrap.json that can be used by "meteor bundle"
users
They are not safe for spaces in paths. There might be other places to look for trouble.
I've run the following command to produce this commit: (on OS X, copy-and-pasting the below exactly)
find . -type f -name '*.sh' -print0 | # Find all .sh files
xargs -0 fgrep -H -- '`' | # See all places with backticks in them
fgrep 'cd `dirname $0' | # I deemed these problematic (variable assignments are safe)
cut -d ':' -f 1 | # Take the <file> from <file>:<line> produced by "grep -H"
tr '\n' '\0' | # Also here, spaces can be problematic - always do "xargs -0"!
xargs -0 -- sed -i '' 's/cd `dirname $0`/cd "`dirname "$0"`"/g'
The significance of adding the two levels of "'s can be verified by running the following in your Terminal:
$ node -e 'console.log(process.argv.splice(1))' -- `echo 1 2`
[ '1', '2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo 1 2`"
[ '1 2' ]
$ node -e 'console.log(process.argv.splice(1))' -- "`echo "1 2"`"
[ '1 2' ]
