This reverts commit 7825ae7845.
test_bundler_npm.js (even after an obvious fix is applied to an unrelated
problem) fails a noticeable percentage of the time in the "bundle multiple apps
in parallel" test. It does not appear to fail on the node-0.10 branch, so will
apply this there instead.
Ha. Turns out that `.call(this)` is needed after all when a
CoffeeScript file is using "use strict".
(http://es5.github.io/#x15.3.4.4)
Thanks to pipedreambomb on stackoverflow for the bug report and to
user1737909 for the documentation reference.
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.
