Sometimes, before dev_bundle/bin/.meteor-commands.json has been written, a
command like `./meteor npx tsc` can fail because `npx` is not blessed in
the same way `node` and `npm` are. Since `npx` is a core tool that we want
folks to be able to use without confusion, I think it makes sense to
include it in the list of known subcommands.
In my local development environment, the `meteor` command resolves to my
Meteor checkout, and I use `~/.meteor/meteor` explicitly when I want to run
a released version of Meteor.
If I run
~/.meteor/meteor npm test
and the `package.json` file defines an npm `test` script that refers to
`meteor`, in my environment this `meteor` won't be the same as the one I
used to run `~/.meteor/meteor npm test`, which can introduce weirdness
such as pinning the versions of packages in `meteor/packages/non-core`,
and all the usual Meteor version inconsistency risks.
This commit fixes that problem by prepending the directory that contains
the `meteor` (or `meteor.bat`) executable to the `PATH` before running
`meteor npm ...` commands.
This was causing problems with `npm@5`, but realistically it may not be
be necessary anymore since `npm@5` has a much smarter global,
self-healing `cacache`.
This is important for `meteor npm`, since we don't parse or pass through
Meteor-specific command-line arguments when running `meteor npm`.
When METEOR_UNSAFE_PERM is set, its value is now propagated to any npm
commands via the NPM_CONFIG_UNSAFE_PERM variable.
Helps with #7959.
Follow-up to #7821.
This will make it easier to use tools like https://yarnpkg.com/ with the
right version of Node, etc.
With this commit, here's all you have to do:
meteor npm install -g yarnpkg
Then test that it works:
meteor yarn info
Note that any commands registered by Meteor itself will not be honored.
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.
