The meteor/tools/isobuild/resolver.js changes are the static half of the
puzzle. The runtime half was implemented in install@0.13.0 with this
commit: 233aa75ce3
We don't need to build a whole new dev bundle just for this upgrade, since
we've already worked around the bug that it fixes, but it will get picked
up the next time we build the dev bundle for Meteor 1.8.2.
This saves us from having to install @babel/parser in the server bundle.
There is currently a bug in Reify that prevents it from loading this
parser by default, but we can work around that on the Meteor side for now.
This partially reverts commit 4dfc74197a.
Some server packages, especially those that rely on __dirname or
__filename (e.g. puppeteer), simply cannot be included in the server
bundle, and must be evaluated natively by Node.
As long as we have a Module.prototype._compile hook to process natively
evaluated modules with Reify, module.useNode() can still benefit from ESM
import/export syntax.
This partially reverts f0d39b86e6 by simply
including .js and .mjs modules in the server bundle, rather than
delegating to pure Node evaluation. In practice, whether or not the
package has a "module" entry point (or "type":"module") in its
package.json was not a perfect indicator of whether it should be compiled
with Reify and bundled, or left untouched and handled by Node.
Truly native modules (such as those with a .node file extension) should
always be handled by Node, so module.useNode() definitely still has a role
to play in the server bundle.
This ensures we wrap modules with a function to rename the `module`
identifier to something more reliable when the ImportScanner compiles
unanticipated modules imported from node_modules.
In PR #10585, I tried enabling full compiler plugin processing for any
modules imported from `node_modules` that were not otherwise handled by
compiler plugins, but doing that for all packages was just too slow, not
to mention potentially dangerous for modules whose code cannot be safely
recompiled by Babel.
The primary reasons for wanting to recompile node_modules are
1. to enable "native" ECMAScript `import`/`export` syntax (given that
Node.js still does not fully support ESM syntax yet), and
2. to compile standard syntax like `const`, `let`, classes, and arrow
functions for legacy browsers.
The first goal can be achieved by compiling unanticipated `node_modules`
code with Reify, which is much faster than Babel, in part because Reify
can avoid doing any parsing when the source contains no `import` or
`export` identifiers. This compilation is also cached on disk, so its
impact should only be felt during cold builds after a `meteor reset`.
The second goal can be accomplished using the new `package.json`
configuration option `meteor.nodeModules.recompile`, which causes the
recompiled packages to be handled by the normal compiler plugins system,
so that the `ImportScanner`'s fallback compilation is not necessary.
Before this option was introduced, this recompilation behavior could be
achieved by symlinking application directories into `node_modules`, but
that always felt like an esoteric hack.
Example:
"meteor": {
"mainModule": ...,
"testModule": ...,
"nodeModules": {
"recompile": {
"very-modern-package": ["client", "server"],
"alternate-notation-for-client-and-server": true,
"somewhat-modern-package": "legacy",
"another-package": ["legacy", "server"]
}
}
}
The keys of the meteor.nodeModules.recompile configuration object are npm
package names, and the values specify for which bundles those packages
should be recompiled using the Meteor compiler plugins system, as if the
packages were part of the Meteor application.
For example, if an npm package uses const/let syntax or arrow functions,
that's fine for modern and server code, but you would probably want to
recompile the package when building the legacy bundle. To accomplish this,
specify "legacy" or ["legacy"] as the value of the package's property,
similar to somewhat-modern-package above. These strings and arrays of
strings have the same meaning as the second argument to
api.addFiles(files, where) in a package.js file.
This configuration serves pretty much the same purpose as symlinking an
application directory into node_modules, but without any symlinking:
https://forums.meteor.com/t/litelement-import-litelement-html/45042/8?u=benjamn
The meteor.nodeModules.recompile configuration currently applies to the
application node_modules directory only (not to Npm.depends dependencies
in Meteor packages). Recompiled packages must be direct dependencies of
the application.
Should fix#10595.
Code from the application `node_modules` directory becomes part of the
`modules` package, so that it can be imported by any other package that
uses the module system, regardless of package load order.
Now that we compile code from `node_modules` using `babel-compiler` and
`meteor-babel` (#10585), `node_modules` code requires the same runtime
environment as any other Meteor JS code. For the most part, this need is
satisfied by the `@babel/runtime/helpers/...` modules, which are also
defined in the `modules` package because they come from `node_modules`.
However, in the legacy bundle, `meteorBabelHelpers.sanitizeForInObject` is
used to fix buggy for-in iteration in older Internet Explorers.
Thankfully, this extra helper code does not need to be included in the
modern or server bundles, but only in legacy code.
