We no longer go to the trouble of generating source maps for files not
processed by compiler plugins, since that was slow and not very useful
(see ad3f56a0bf).
However, that means the test app and package that we use to test source
maps and stack trace rewriting need to use the ecmascript package in order
to behave as they did before that commit.
Though I would like to transition to using unibuild.nodeModulesDirectories
everywhere, the cosmos:browserify package assumes more than I would like
about the pre-Meteor-1.3 properties of unibuild objects.
Fixes#6449.
Because symlinking is impossible on Windows, and copying node_modules
files is too slow, we can't just symlink/copy all node_modules files into
.meteor/local/build/programs/server/npm like we do for other platforms, so
we have to search for them where they are.
Part of #6500.
To ensure we don’t hot code push JavaScript that is incompatible with
the bundled native code, we calculate a hash based on the platform and
plugin versions.
When we call readAndWatchFileWithHash, if the file does not exist, we
still want to add it to the watchSet with a null hash. Later, however, we
have to be careful we do not assume every file in watchSet.files exists.
If you have a lot of packages and you change something in a package that
is used by lots of other packages, such as "meteor" or "modules", then the
rebuild can take a lot longer than ten seconds.
Versions 2.x and 3.x of npm prefix internal package.json fields with
underscores, though `npm shrinkwrap` removes the underscores, so fields
like "_resolved" become just "resolved" in the shrinkwrap file.
This commit also fixes#5940.
I think we hadn't done this for back-compat reasons, however it doesn't make sense as it means that test-drivers and test utilities can't be `testOnly` if they want to be usable for `meteor test-packages`. Which kind of makes it pointless to have `testOnly`.
I don't anticipate it will cause problems, but I'm not entirely sure.
