Support the "module" field of package.json for client code. #10541
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benjamn
force-pushed
the
support-module-field-of-package.json-on-client
branch
from
c1b3661
to
36c0090
Compare
benjamn
force-pushed
the
support-module-field-of-package.json-on-client
branch
from
36c0090
to
9c1769f
Compare
benjamn
force-pushed
the
release-1.8.2
branch
2 times, most recently
from
ada62d5
to
f4b92a0
Compare
Supporting "module" in package.json for server code is not advisable because Node.js will be adopting the "type":"module" convention instead, and in the meantime we need to maintain consistency with Node's module resolution rules, which only currently pay attention to "main": https://medium.com/@nodejs/announcing-a-new-experimental-modules-1be8d2d6c2ff
benjamn
force-pushed
the
support-module-field-of-package.json-on-client
branch
from
9c1769f
to
c0cc2e3
Compare
This was referenced May 3, 2019
benjamn
added a commit
that referenced
this pull request
May 4, 2019
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.
This was referenced Jun 25, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Like Node.js, Meteor's module system currently pays attention only to the
"main"field ofpackage.jsonfiles (and also"browser"on the client) when resolving package entry points. This behavior effectively limits Meteor to using the CommonJS version of any npm packages, even though many packages have both a CommonJS and an ECMAScript module (ESM) entry point.This PR enables support for the
"module"field for client code. The implementation required a few small adjustments: in particular, we now compile.jsfiles withinnode_modulesif they are contained by a package that has a"module"entry point (only if theImportScannerdecides the module is actually used), and our module resolution logic now prefers the"module"entry point both during build (resover.js) and at runtime (modules-runtime).Why is this important? Supporting ESM syntax everywhere is the future of JavaScript, first and foremost. Also, wherever ESM syntax is used, it's important for Meteor to have a chance to compile it, since we have an advanced module compiler called Reify.
Supporting
"module"inpackage.jsonfor server code is not advisable because Node.js will be adopting the"type": "module"convention instead, and in the meantime we need to maintain consistency with Node's module resolution rules, which only currently pay attention to"main".