Skip to content
This repository has been archived by the owner on Aug 4, 2021. It is now read-only.

Own package.json browser field not consulted for module replacements #228

Closed
bterlson opened this issue Jun 20, 2019 · 3 comments
Closed

Comments

@bterlson
Copy link
Contributor

bterlson commented Jun 20, 2019

  • Node-Resolve Plugin Version: 5.x
  • Rollup Version: Latest
  • Operating System (or Browser):
  • Node Version: 10.x

How Do We Reproduce?

Given a library with a package.json browser entry like:

"browser": {
  "buffer": false,
  "stream": "./node_modules/stream-browserify/index.js",
  "src/index.node.js": "src/index.browser.js"
}

Now run rollup on this library.

Expected Behavior

I expect buffer to be excluded from the bundle, and stream to be replaced with stream-browserify.

Actual Behavior

Errors related to depending on node built-ins.

If we roll up a dependency on this library, everything works as expected. However, if we roll up the library itself, these fields are not consulted. The reason is that the plugin will not read package.json browser field without first resolving an import to that module. File replacements as in the last example work fine because importing e.g. ./index.node.js will resolve to the local package with the package.json browser field loaded. "buffer" and "stream" will fail to resolve, however, and so we never get a chance to examine the package.json browser field.

I would write a PR fixing this issue, but I'm actually not sure how to test this properly since the test samples don't seem to have their own package.json files and I'm not sure where it would make sense to put one.

@bterlson
Copy link
Contributor Author

bterlson commented Jun 20, 2019

Upon further investigation, this only applies to modules imported from the main entry point of the package, i.e. when importer is undefined.

@bterlson
Copy link
Contributor Author

Upon even further investigation, this also only applies when the project's input config isn't a relative or absolute path. If your input starts with ./, everything works fine.

@bterlson
Copy link
Contributor Author

This was fixed in #229.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant