Static CSS gets merged in development as well as production by
ClientTarget#minifyCss; the only difference is that the CSS is also
minified in production. This development-time merging is especially
expensive because it involves source maps, and happens on every rebuild of
the app. That's why ClientTarget#minifyCss consistently shows up in
METEOR_PROFILE output for rebuilds.
The standard-minifier-css package tries to cache the merging based on the
hashes of the input files:
8a562523a4/packages/standard-minifier-css/plugin/minify-css.js (L58-L62)
However, not all CSS minifier plugins use a strategy like this, and
https://atmospherejs.com/juliancwirko/postcss is an increasingly popular
one that does not.
The time has come to move this caching logic into the Meteor build tool
itself, so that CSS minifier plugins no longer have to worry about basic
caching, and everyone who uses CSS minifiers with Meteor will benefit.
This implementation leverages Meteor's powerful optimistic caching
techniques to keep previous results in memory only as long as the minifier
object remains reachable.
Since markBoundary is essentially creating a bound wrapper function,
there's no reason we can't actually bind the function to a specific
context (this) object at the same time, instead of having to bind the
function and then wrap it with buildmessage.markBoundary.
With lazy compilation, it should be cheap to pass a ton of files to
processFilesForTarget, as long as only a small percentage of them are
actually used by the application.
Before this change, every inputFile passed to processFilesForTarget would
get its own async function, which took considerably more time to resolve
than using Promise.await inside getResult to handle any Promise returned
by the compileOneFile method.
In other words, this change should significantly reduce the METEOR_PROFILE
timings for items like "other plugin less..." especially during rebuilds,
when very few files actually need to be recompiled.
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.
This enables using index.* modules with non-.js file extensions to make
the containing directory importable (cc @justinanastos):
c417044421
Since this is a core package patch update, you can update to this version
of the modules-runtime package by running
meteor update modules-runtime
This should give you modules-runtime@0.10.1.
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.
