I recently noticed a bug whereby modules transferred from the application
bundle to the modules bundle would lose their application-specific import
extensions, since all modules installed in the modules bundle have only
.js and .json as import extensions, matching default Node behavior.
This commit fixes that bug by emitting one meteorInstall call per distinct
meteorInstallOptions object. This logic would work if every module had a
different meteorInstallOptions object, but in practice the modules bundle
should end up with exactly two meteorInstall calls, because a single
options object is shared among all modules from the same source batch.
This should be a better fix for the problem I tried to fix with
479e505d71.
If we're going to be using compileOneFileLater by default, that's what we
should be testing in the compiler plugins self-tests.
The concept of a "root" file is specific to MultiFileCachingCompiler, so
we need to normalize it into a representation that makes sense to the rest
of the compiler plugin system.
Should help with #10014.
The previous commit enabled importing index.* modules at runtime, but
unfortunately the build-time Resolver logic also needed updating, which
will require a new Meteor release.
When a CSS (or compiled-to-CSS) module is lazy (e.g., in `imports/` or
`node_modules`) and not otherwise imported by another CSS module, Meteor
automatically turns it into a JS module so that it can be handled by the
`ImportScanner`, and imported dynamically by other JS modules.
Until now, there were two problems with CSS handled in this way: it did
not have proper source maps, and the CSS text was not minified in
production.
This commit introduces a special minification step for dynamic CSS, which
must take place before we create the dynamic JS module. Waiting for the
usual minification of CSS would be a mistake, since that happens long
after the `ImportScanner` and `Linker` have already processed JavaScript
modules. Modifying the contents of JS modules at that point would be
impossible without recomputing source maps, etc.
Since the JS module dynamically creates a `<style>` tag and appends it to
the `<head>` of the document, the code of the JS module has no meaningful
relationship to the lines of CSS text that are actually evaluated by the
browser, so it would be a mistake to give the JS module the same source
map as the original CSS resource.
Instead, when there is a source map, we write it out as an asset that can
be requested at runtime, and append a sourceMappingURL comment to the end
of the CSS text referring to this asset URL. Note that this only happens
in development, which makes sense because minification in production
invalidates the source map, and we don't want to expose source code in
production anyway.
According to traditional Meteor file loading rules, tests/ directories are
completely ignored: https://guide.meteor.com/structure.html#special-directories
However, if you specify a meteor.testModule in your package.json that
refers to a file inside a tests/ directory, Meteor should permit modules
to be loaded from tests/, as well as any modules that are imported by the
meteor.testModule entry point.
Fixes#9991.
One limitation of Meteor's current compiler plugins system is that every
file we *might* use must be compiled before we know whether it *will* be
used by the application (which is something we only find out when we later
run the `ImportScanner`). More specifically, when inputFile.addJavaScript
is called, any information relevant to the current file must already have
been computed, even if the file will never be used.
This commit begins the process of supporting a lazy version of the
`inputFile.addJavaScript` method. For consistency, this interface is
supported by other methods like `inputFile.addStylesheet`, though it may
not make as much sense for non-JavaScript resources.
In this very basic initial implementation, the `lazyFinalizer` function is
called immediately, so that subsequent code can keep pretending that all
relevant information was eagerly provided.
The next step will be waiting to call `lazyFinalizer` until the last
possible moment, so that we can skip a potentially huge amount of
unnecessary compilation time.
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
