Preserve true "main" and "browser" fields of package.json modules. #8213
Conversation
Previously, when building a JavaScript bundle for the client, if a package.json file had a string-valued "browser" field, we would replace the value of the "main" field of the bundled package.json module with the value of the "browser" field. This trick was important because it allowed an npm package to have a different entry point on the client than it had on the server. However, that approach became inconsistent if the package.json file was also explicitly imported as a module, because the package.json stub used for module resolution prevented the real contents of package.json from getting bundled, and disagreed with the original package.json module about the value of the "main" field. To resolve that inconsistency, it seems better to avoid modifying the "main" field of package.json modules, and instead rely on the runtime module system to make sense of the "browser" field, regardless of whether the package.json module is a stub used only for module resolution or contains the full contents of the original package.json file. The ability to understand "browser" fields of package.json modules was introduced in install@0.8.3: benjamn/install@377d1a3 This is potentially a backwards-incompatible change for developers using this version of `ImportScanner` and `Resolver` who have not yet upgraded their `modules-runtime` package to at least version 0.7.8. The solution is to upgrade `modules-runtime`, though it would be nice to enforce that better somehow.
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.
Previously, when building a JavaScript bundle for the client, if a
package.json
file had a string-valued"browser"
field, we would replace the value of the"main"
field of the bundledpackage.json
module with the value of the"browser"
field. This trick was important because it allowed an npm package to have a different entry point on the client than it had on the server.However, that approach became inconsistent if the
package.json
file was also explicitly imported as a module, because thepackage.json
stub used for module resolution prevented the real contents ofpackage.json
from getting bundled, and disagreed with the originalpackage.json
module about the value of the"main"
field.To resolve that inconsistency, it seems better to avoid modifying the
"main"
field ofpackage.json
modules, and instead rely on the runtime module system to make sense of the"browser"
field, regardless of whether thepackage.json
module is a stub used only for module resolution or contains the full contents of the originalpackage.json
file.The ability to understand
"browser"
fields ofpackage.json
modules was introduced in install@0.8.3: benjamn/install@377d1a3This is potentially a backwards-incompatible change for developers using this version of
ImportScanner
andResolver
who have not yet upgraded theirmodules-runtime
package to at least version 0.7.8. The solution is to upgrademodules-runtime
, though it would be nice to enforce that better somehow.