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.
This specifically would happen if you ran an app with at least one sub with a
ready message (ie not autopublish; eg parties) with auth, logged in, and then
killed the app and replaced it with a different app. Hot code push would stall
and the new app would not load until you hit reload.
Why? Due to the login method call, hot code push had to wait for the login
method to be done. A method being done, in this case, includes having all its
data visible. This means waiting for the at-reconnect global quiescence to
finish. But this would never happen, since that requires waiting for all subs
that had been ready to become ready again, and instead the subs were getting
nosub because this is an entirely different app.
