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 is a follow-up to b4a68e99c1, which
allowed obtaining a simplified list of build architectures (without
web.browser.legacy) by calling isopack.buildArchitectures(true), which was
helpful for matching existing builds of packages that were published
before the web.browser.legacy architecture was introduced in Meteor 1.7.
Now that some packages have been published with the web.browser.legacy
architecture as part of the Meteor 1.7 release, it's important to try
matching the full unsimplified list of architectures, while still falling
back to the simplified list for other packages.
This reverts commit c5302bb2ba.
Based on conversation with @KoenLav, it seems this optimization was more
of a breaking change than anticipated, and the workaround of creating a
symbolic link to induce compilation is not just annoying on Windows but
also does not satisfy the goal of being able to import from node_modules
(as before) rather than importing via the symbolic link.
We will need to revisit this pitfall in Meteor 1.7.1, but it's important
to unbreak it ASAP in Meteor 1.7.0.1 (since 1.7 is unfortunately final).
https://github.com/meteor/meteor/pull/9826#issuecomment-392596129https://github.com/mozfet/meteor-autoform-materialize/issues/43
For apps that are accidentally compiling too many LESS or SCSS files, the
recommended workaround (for now) is to add the offending directories
and/or files to a .meteorignore file.
