When I implemented support for the "module" entry point in package.json
files for client code in #10541, I modified PackageSource#_findSources to
include files found in node_modules that need to be compiled, but my
implementation considered only "local" node_modules directories, like the
one in the application root directory, while neglecting the private
.npm/package/node_modules directories that many Meteor packages have.
This commit includes .npm/**/node_modules when _findSources is scanning a
Meteor package, which should solve issues like #10544, where a Meteor
package imports an npm package that was installed with Npm.depends, and
that npm package has a "module" field in its package.json file, pointing
to an ESM entry point module, but the ESM syntax was not appropriately
compiled, leading to parse errors like "Unexpected token export".
Before lazy compilation was introduced in Meteor 1.7 (#9983), including
the node_modules directories of Meteor packages would likely have been a
big problem for build performance, since there would be that many more
modules to compile. It's still worth making sure this change doesn't
regress build performance for other reasons, but I'm reasonably confident
lazy compilation will save us here, unless there are just too many npm
packages installed via Npm.depends that export ESM modules.
Fixes#10393.
Bumping compiler.BUILT_BY and LINKER_CACHE_SALT because
PR #10414 changes the behavior of the build system in a subtle way that
does not automatically trigger recompilation.
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.
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.
This functionality was added in reify@0.13.3:
10c90cd0a2
The changes to modules-test-plugin/plugin.js cause files like array.arson
to mirror array.arson.js, which exercises module.makeNsSetter(true) and
relies on default exports.
When the babel-compiler package is processing files, it will now read
their package.json files looking for a "babel" section with "presets" or
"plugins" fields. If found, these presets or plugins will be appended to
the existing babelOptions.presets or babelOptions.plugins arrays.
Note that no other Babel options are currently supported, and the
"babel-preset-meteor" preset cannot be removed, though additional presets
and/or plugins can be added to it. This is by design: Meteor cannot
support your configuration it uses babel-preset-meteor, at least.
The preset and/or plugin modules listed in package.json must be installed
locally somewhere such that the given file can import them. If they are
top-level identifiers, they will be prefixed with "babel-plugin-" or
"babel-preset-", the same as Babel does it. Otherwise they will be
required as-is, so that you can implement your own Babel plugins locally,
rather than always using plugins installed from npm.
See the included tests for a concrete example.
Fixes#6351.
These changes allow Package.registerCompiler-style compiler plugins to
extract package.json and npm package information at compile time from the
files that the plugin processes.
This information was accessible before, but it certainly wasn't easy to
obtain it. These convenience methods should satisfy the motivation behind
This allows packages to import npm packages they have not installed, with
the expectation that the app developer will provide those dependencies by
installing them into the top-level node_modules directory in the app.
For example, an app can now `npm install react` and that npm package can
be used by any package as well as by the app.
