This is to isolate the NPM dependencies of the package at runtime from the NPM
dependencies of any build-time plugins in the package, which live in
PACKAGE/.npm/plugin/foo.
Before, plugins could see the node modules at PACKAGE/.npm/node_modules, which
was not isolated enough.
(One issue would be that if you happened to switch a package from having runtime
dependencies to having buildtime dependencies, the buildtime dependencies would
not get installed. This is partially an issue because we don't know to uninstall
all dependencies if they are all removed, but even if that is fixed it would
enforce an unnecessary ordering semantics on NPM updates.)
Server assets can be included in a bundle by putting them in the private/
directory of an application, or by registering a build plugin that calls
compileStep.addAsset with a server file. The Assets API (Assets.getText and
Assets.getBinary) allows an application or package to retrieve the contents of
its own server assets.
With the precedence bug fixed, more directories are placed into
usedAsFile... enough to break nodeModulesMode=symlink. Fortunately bundler-test
did catch this.
The somewhat hacky fix is to look carefully for reserved empty directories and
replace them with symlinks. This may not be 100% correct; see the XXX comment.
(On Galaxy, start.sh deletes node_modules anyway.)
Normally you wouldn't use bundle to create things meant to be deployed (you'd
use deploy!) but Galaxy development itself consists of building things with
"bundle" to be assembled into a Galaxy.
They really only work well (ie, restart properly after reconnect) if they have
an increasing BSON Timestamp() field named ts. Sorry, that's just how Mongo
works.
Use them for "meteor logs" in Galaxy mode.
Set $NODE_ENV appropriately (to 'development' in 'meteor run' and 'production'
otherwise) so that connect doesn't send stack traces over the network in
production.
Set $NODE_ENV appropriately (to 'development' in 'meteor run' and 'production'
otherwise) so that connect doesn't send stack traces over the network in
production.
This was broken by 957729c, which switched the child process listener from
'exit' to 'close' but didn't update another line which removed that listener. So
we had an allergic reaction to killing our own subprocess.
