Previously to fixing #927, if you had a 'node_modules' directory
anywhere up the directory tree from your app and you had a package
in your app using NPM, all calls to 'npm' ran against the 'node_modules'
directory it found, so neither 'node_modules' nor 'npm-shrinkwrap.json'
would be created within your package's .npm directory.
The fix to #927 ensured that 'node_modules' was first created within
'.npm' but people who had already run 0.6.0 were still in a corrupted state.
one-time content scan. Addresses Issue #223.
This addresses two cases: files that change during a slow bundle (eg, during
slow NPM updates) and *do* end up with a different mtime (which could also be
addressed in other ways, see eg the issue-223-dead-end branch)... and those that
change twice within the same second on OSX HFS+ which only has 1-second mtime
resolution, which really cannot be addressed in any purely mtime-based way.
This still is not 100% perfect. Most notably, any files read via
register_extension (which is to say, basically all source files other than
package.js and static resources) still have a race between hash calculation and
the actual read done by the bundler, since the register_extension API takes a
source_path rather than contents. This could be addressed by making
register_extension handlers take the contents as an argument too (and encourage
the use of source_file only for things like printing errors with filenames, not
actually for reading the file). In addition, this won't detect files added after
the bundler passes them but before the initial DependencyWatcher run.
(the non-springboarding piece of that is now controlled by
METEOR_TEST_NO_SPRINGBOARD)
This means that run-all-tests.sh can use launch-meteor to bootstrap a warehouse
instead of starting with an empty warehouse directory (which is no longer
allowed).
also, fix npm module usage out of the bootstrap tarball: we were too liberal in
the "never update npm dependencies in the warehouse" rule since the bootstrap
tarball would contain packages with no node_modules (or if we had a failure
between downloading a package and running installNpmDependencies). instead,
"never update npm dependencies in the warehouse if .npm/node_modules already
exists".
