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.
See #7495. Still some decisions to be made:
- Should we make --all-packages the default?
- How should we deal with *new* indirect dependencies?
- Should we do anything about underpinning indirect dependencies when updating?
Since we do not write .meteor-last-rebuild-version.json files when
developers run `meteor npm install ...`, this commit saves us from
unnecessarily rebuilding any freshly-installed binary npm dependencies
when Meteor starts.
These packages need to be installed when we run `npm install` in
`bundle/programs/server` (which this commit ensures), but they don't need
to be part of the dev bundle.
Breaking on the first statement in the program used to be the only way to
get the debugger to stop at any breakpoints, but more recent versions of
node-inspector (compatible with Node 4) do a much better job of stopping
at breakpoints after the program starts.
* Include process.{platform,arch} in .meteor-last-rebuild-version.json.
This supports rebuilding binary npm packages published by completely
different architectures, not just different versions of Node.
* Make publish-for-arch unnecessary in most cases.
* Don't rebuild binary packages when Node patch version changes.
* Permit patch-compatible versions in .meteor-last-rebuild-version.json.
This is a more general solution than simply discarding the patch version
for currentVersions.versions.node, as I did in a previous commit.
This will make it much easier to fix bugs and make improvements going
forward, since they won't have to wait for the next release of Meteor.
One functional change: when the parent process exits, it no longer forces
all connected shell clients to disconnect, which is actually a more
convenient behavior, because it gives the clients a chance to reconnect
when/if the server starts up again, and it's easy enough to kill the
clients if that's what you want.
