Prefer "main" field of package.json over "module" in legacy bundle. #10765
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
added 2 commits
November 8, 2019 11:15
#10658 (comment) #10658 (comment) As usual, changes to module resolution logic need to happen in parallel in tools/isobuild/resolver.ts and in packages/modules-runtime. However, thanks to the modern/legacy system, it's easy to make the modules-runtime package behave exactly the way(s) we want in the server, modern client, and legacy client bundles.
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.
Before Meteor 1.8.2, all bundles avoided using the
"module"field ofpackage.json, in favor of either the"main"field or (when building/running a client-side bundle) the"browser"field.During the development of Meteor 1.8.2, we have tried several different strategies to begin using the
"module"field when possible, before falling back to the"main"field, which should unlock future optimizations likeimport/export-based tree shaking.While everything appeared to be working from a logical standpoint, the practical reality is that many npm packages ship dangerously modern syntax like
constand arrow functions in the code identified by their"module"fields, not justimportandexport. This is regrettable, since it means the legacy bundle cannot simply include these npm packages'"module"code without first recompiling it down to ES5. In other words, our decision to prefer"module"over"main"would have made it necessary to add a lot more npm packages to themeteor.nodeModules.recompilelist, as @smeijer found in #10658 (comment).This PR reverses the precedence of
"module"and"main"for legacy bundles only, so that legacy client builds will go back to behaving the way they behaved in Meteor 1.8.1. This may limit the impact of tree shaking for the legacy bundle in the future, but that's acceptable because it's more important for the legacy bundle to work correctly (without a lot of manual reconfiguration) than to be as small as possible.Thanks to @smeijer for this idea! #10658 (comment)