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.
Now that getResolver takes options, it seems inappropriate to cache only
the first resolver created, since multiple resolvers might be created with
different options.
Fortunately, caching Resolver objects is not strictly necessary (even for
performance), since Resolver.getOrCreate already caches based on the
options it receives.
The only other meaningful work PackageSourceBatch#getResolver was doing
was computing the nodeModulesPaths option, so I've cached that.
When we copy node_modules directories during rebuilds, we try to create
symlinks instead of doing a full recursive copy. Very often, however, the
symlinks already exist, and they point to the right location already, so
we can avoid recreating them for even better performance.
Another optimization identified by using the qualia:profile package
created by @veered: https://atmospherejs.com/qualia/profile
This only affects newly created applications for now, but developers can
update to the latest meteor-node-stubs by running
meteor npm install meteor-node-stubs@latest
https://github.com/meteor/node-stubs/issues/15
All Meteor packages implicitly depend on the meteor package, and the
meteor-base package implies the meteor package for most Meteor apps, but
the new minimal skeleton does not use meteor-base, so minimal Meteor apps
were not directly depending on the meteor package.
The only reason this mattered was that the meteor package registers a
default compiler plugin for CSS files, and compiler plugins only apply if
an app or package directly depends on them (or depends on a package that
implies them, such as meteor-base).
In other words, this change reenables support for raw CSS files for
minimal apps.
This still leaves web.cordova as the only architecture whose URLs get
prefixed (with /__cordova/), but the implementation better reflects the
special status of web.browser and web.browser.legacy as architectures that
the webapp and dynamic-import packages understand how to disambiguate
using the isModern test from the modern-browsers package.
Now that webapp can differentiate between modern and legacy browsers when
serving static files, without relying on URL prefixes, in principle we
shouldn't have to use prefixes for any URLs except Cordova ones.
* add resource-file to mobile-config
* Fix typo in addResourceFile documentation header
* get filename with path.parse instead of split
* Code formatting adjustments
This functionality was originally intended to allow importing
compiled-to-JS modules from `node_modules`, by precompiling any modules
found in top-level npm packages, as long as a Meteor compiler plugin was
registered for the module's file extension.
As discussed in #9800, this extra compilation burden can be non-trivial,
especially if you happen to install an npm package such as `less`, which
contains hundreds of `.less` files in the `node_modules/less/test/`
directory.
More generally, this functionality was an early attempt to enable
selective compilation of `node_modules` directories, but it was not a good
solution to that problem, because in almost all cases the extra
compilation was unwanted.
Meteor 1.7 (formerly known as 1.6.2) will give full control over selective
compilation of `node_modules` back to the application developer (#9771),
which should afford a much better solution to this problem. If you've
installed some `.less` or `.scss` or `.ts` files from npm into your
`node_modules` directory, just create a symlink to the package directory
within your application, and those modules will be compiled and become
importable by other JS modules, as if they were part of the application.
