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?
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.
As a refinement of my previous commit, we will continue setting the
$GYP_MSVS_VERSION variable to "2015" except in cases where the Python
library behind node-gyp succeeds in inferring the correct version.
Note that the Python library will never infer "2015" by itself, even
though that's the version recommended by the node-gyp setup instructions:
https://github.com/nodejs/node-gyp#installation.
Note also that the Windows machines used by `meteor admin get-machine` and
build.meteor.com have version "2010e", which can be inferred.
In other words, this commit allows the following groups of developers to
avoid setting $GYP_MSVS_VERSION manually:
1. Developers who followed the node-gyp setup instructions.
2. Package authors who run `meteor publish-for-arch` on build machines.
Setting GYP_MSVS_VERSION to 2015 when the Visual C++ 2015 build tools are
not (and/or cannot be) installed is (in my experience) the leading cause
of `npm rebuild` failures on older Windows machines.
Auto-detecting the appropriate version is something node-gyp ought to be
able to do as well as Meteor possibly could, at least according to
https://github.com/nodejs/node-gyp/blob/1dcf356ca7/gyp/pylib/gyp/MSVSVersion.py#L222-L223
When selecting a different version is important, you can always set the
GYP_MSVS_VERSION environment variable yourself. Specifically, if you're a
package author, and your package depends on npm packages that can only be
compiled with a newer version of MSBuild.exe, then you might need to run
$env:GYP_MSVS_VERSION = "2015"
meteor publish-for-arch name:package@x.y.z
I fully trust that the folks in that small category can handle that
additional burden.
I'm deliberately leaving in the code to ensure .meteor/.gitignore contains
dev_bundle for now, so that the old file won't get accidentally checked
into anyone's app repository.
I'm deliberately leaving in the code to ensure .meteor/.gitignore contains
dev_bundle for now, so that the old file won't get accidentally checked
into anyone's app repository.
This wouldn't work if .meteor/dev_bundle needed to be a true symbolic
link, but fortunately we just need to record the target path in a way that
allows us to read it later.
Fixes#7374.
Because the cache directories are shared instead of copied, the results
now have a chance of surviving multiple invocations of `meteor test`.
This significantly reduces rebuild times when testing a large app; for
example, the meteor/tools/tests/apps/modules app now takes less than 10
seconds to rebuild (after restarting the process, not after a file change)
instead of 60 seconds or more.
Because the cache directories are shared instead of copied, the results
now have a chance of surviving multiple invocations of `meteor test`.
This significantly reduces rebuild times when testing a large app; for
example, the meteor/tools/tests/apps/modules app now takes less than 10
seconds to rebuild (after restarting the process, not after a file change)
instead of 60 seconds or more.
