Should resolve#10233, reported by @klaussner.
Previously, if a compiler plugin called inputFile.addJavaScript multiple
times with different { path } strings, Meteor would allow importing all of
those modules at once by importing the original source module identifier,
by synthesizing a new source module containing a series of re-exports for
each of the generated modules.
Preserving this behavior is important for backwards compatibility, since
some compiler plugins still generate files like "module.ext.js" given an
input file named "module.ext", so Meteor tries to make those modules
interchangeable/synonymous.
However, if the compiler plugin explicitly calls inputFile.addJavaScript
with the original source path, then it would be a mistake to modify the
contents of that module, so Meteor will now leave the contents of that
explicit source module unmodified, rather than using it as a catch-all way
to import other generated modules.
Follow-up to af51b816, which fixed#8005 by copying symlinks to external
directories as directories rather than trying to preserve the symlinks.
Issue #10177 revealed a flaw in this strategy: the filter function that we
use to strip development npm packages always rejects external paths, even
if the original symlink was found in a valid production npm package, and
thus its contents should be included in the production bundle.
In the process of fixing this problem, I realized that the only important
part of af51b816 was this code:
// Update fileStatus to match the actual file rather than the
// symbolic link, thus forcing the file to be copied below.
fileStatus = optimisticLStatOrNull(externalPath);
and the code for manipulating thisAbsFrom and _currentRealRootDirectory
could be removed.
According to the plan described in #10134, whereas we had to pin these
versions to exactly 7.0.0-beta.55 for Meteor 1.7.0.4, we must now require
at least 7.0.0-beta.56 for Meteor 1.7.1, since other @babel/... packages
used by babel-compiler and meteor-babel are currently at beta.56.
The ImportScanner was mistakenly generating module.useNode() stub modules
for local .json files within Meteor packages, just because their absolute
module identifiers include "node_modules", which happens because we put
package modules under the /node_modules/meteor/<package name/ namespace.
Fix: make logic for determining when to generate module.useNode() stubs
match Module.prototype.useNode logic in modules-runtime/server.js.
Closes#10122.
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.
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 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.
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
