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.
