New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve true "main" and "browser" fields of package.json modules. #8213

Merged
merged 1 commit into from Jan 4, 2017

Conversation

Projects
None yet
1 participant
@benjamn
Member

benjamn commented Jan 4, 2017

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.

Preserve true "main" and "browser" fields of package.json modules.
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.

@benjamn benjamn force-pushed the package-json-browser-field branch from ecefcfb to 514554b Jan 4, 2017

@benjamn benjamn self-assigned this Jan 4, 2017

@benjamn benjamn added this to the Release 1.4.3 milestone Jan 4, 2017

@benjamn benjamn merged commit 2eab0b2 into devel Jan 4, 2017

4 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@abernix abernix referenced this pull request Feb 3, 2017

Merged

Release 1.4.2.5 #8311

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment