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.
Note there are a few use cases I can think of we want to worry about:
`meteor run` -- both should be "development"
`meteor run --production` - both should be "production"
`NODE_ENV=production meteor run` - as above
`NODE_ENV=development meteor run --production` - `--production` should win
`meteor test` - NODE_ENV should be "development", buildMode should be "test"
`NODE_ENV=production meteor test" - NODE_ENV should be "production", buildMode should be "test"
What happened to beta.13, beta.14, and beta.15? All unfortunately suffered
from problems that made it either impossible or unwise to upgrade to those
versions.
Packages published with node_modules unibuild properties that are
object-valued instead of string-valued cannot be loaded by the previous
version of meteor-tool, so the tool can't upgrade itself if any packages
have object-valued node_modules properties. Fortunately, no packages
currently exist that need both Npm.depends and local node_modules
directories, so we can just keep writing strings for now. At some point in
the future (maybe 1.3.1), we can assume people have upgraded to a version
of the tool that supports object-valued node_modules properties, and then
we can start writing those properties to disk without worrying about
old versions of the tool.
