I originally added the exception-caching functionality in order to avoid
calling files.stat repeatedly for files known to be missing, but now that
we're using statOrNull, knowledge of missing files (as indicated by
statOrNull returning null) is being properly cached.
The reason it's dangerous to cache exceptions is that (for example) when
an ENOENT exception indicates the file is missing, there will be no more
change events for that file, effectively making the exception permanent,
even if the file comes to exist at a later time.
As a reminder, we use fs.watchFile only as a fallback in environments
where pathwatcher.watch is not available, such as on network or virtual
file systems.
This saves a potentially large amount of work by the ImportScanner and the
Resolver during makeServerTarget, because it means we no longer have to
scan and resolve modules to build a server bundle as a backup for native
Node evaluation.
I've attempted this optimization before, but it wasn't really safe until
I fixed some obscure bugs that caused module.useNode() to fail during
`meteor test-packages` (see recent local-test:-related commits).
Revert "Write node_modules metadata as single strings."
This reverts commit f74975d0df.
Packages published with multiple node_modules directories won't be
loadable by versions of Meteor before 1.3, because older versions of
Meteor don't understand object-valued isopack "node_modules" fields, but
the vast majority of Meteor developers are now using either 1.3 or 1.4.
Typically all outstanding watchers will be closed when the development
server restarts, but we can save a lot of effort if they survive the
restart, for the small cost of keeping them open for an extra 30sec.
For the galaxy-server application, this reduces the time spent in
watch.isUpToDate from six seconds to a little over second. Of course we
should also try to call it less often, but making it cheaper helps!
For the galaxy-server application, this reduces the time taken to
determine production node_modules from 1400ms to 120ms.
As another optimization, we could record the hashes of all the
package.json files encountered in this scan, and return the same set of
production package names if those hashes have not changed, though the
benefits may not be worth the additional complexity.
Now that the blaze submodule is mounted inside the packages/non-core/
directory, it appears that we no longer have to mention it explicitly in
the localPackageSearchDirs array.
After recent discussion on https://github.com/meteor/meteor/issues/7401,
@glasser and I think the relatively obscure benefit of --no-bin-links is
outweighed by the problems it causes for packages whose rebuild scripts
need executable scripts installed in the node_modules/.bin/ directory.
