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.
According to the README, this implementation is approximately 2.7 times
slower than native: https://www.npmjs.com/package/bcryptjs
Apps that wish to continue using the native bcrypt package should run
`meteor npm install --save bcrypt` in the root application directory, and
the npm-bcrypt package will prefer that implementation.
Needed to add version constraints to all the dependencies in
accounts-base/package.js so that I can publish it independently from a
Meteor release.
Follow-up to #7534.
Fixes#7611.
The previous code did not accommodate the possibility that
`meteorNpm.getProdPackageNames` might return a package name that contained
one or more `/` characters.
Fixes#7579.
This is necessary to allow publishing accounts-password independently of a
Meteor release.
Note that the npm-bcrypt version has been bumped to 0.8.7_1.
The node-gyp tool uses `process.env.HOME || process.env.USERPROFILE` to
determine where it should install the .node-gyp directory containing Node
headers and libraries, and we now preinstall that directory at
dev_bundle/.node-gyp/, so (with this change) no download should be
necessary.
This gives us a reliable place for node-gyp to find the necessary headers
and libraries for compiling binary packages, instead of relying on the
accessibility of $HOME and/or $USERPROFILE.
This reverts commit 64a9312e29.
Although Meteor runs fine on Node 4.5.0, node-gyp doesn't know how to
download libraries appropriate for RC releases, so it looks like we need
to hold off on this upgrade until it's officially out.
We shouldn't be processing .css files on the server anyway, because of a
similar restriction in packages/meteor/plugin/basic-file-types.js, but
it seemed wise to enforce that restriction redundantly here.
