Skip to content
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

Impossible to implement safely with deduplicated dependencies? #2

Open
joepie91 opened this issue Jan 14, 2016 · 1 comment
Open

Impossible to implement safely with deduplicated dependencies? #2

joepie91 opened this issue Jan 14, 2016 · 1 comment

Comments

@joepie91
Copy link

According to the specification:

If a module you depend on already includes a browser field, then you don't have to do anything special. Whenever you require that module, the bundler SHOULD use the hint provided by the module.

... however, would this even be possible when using deduplicated dependencies, eg. when using NPM 3 or after manually deduplicating in NPM 2?

The specification is not very explicit about how this is to be implemented, but I can see three possible approaches:

  1. Every browser field specified by every package is applied globally to all packages (including to dependencies that are not its own) from the moment it is encountered. This creates potentially unsafe global state, and might lead to weird bugs.
  2. The browser field in a module's package.json only applies to its dependencies. However, this is not possible when deduplicated - there might only be one copy of a specific subdependency for two different dependencies (it might not even be in the module's node_modules folder!), and only one of them might want to override the require. Again, global contamination.
  3. The browser field in a module's package.json only applies to immediate dependencies, when required from that module's code. This means modules can no longer be cached (posing a possibly severe performance issue), "dependency tracking" logic has to be introduced, and it's not possible to forcibly override a subdependency without cooperation of the author of the 'higher-level' dependency. This does not seem workable either.

Can you see any way in which it would be viable to allow a module to specify a browser field? This seems like fairly important functionality (eg. Webpack's approach of "copy this to your webpack configuration if you use this module" is not very sustainabble), but I'm struggling to see a way in which this is actually possible.

@steelbrain
Copy link

This is actually very simple, the problem here is that deduping disrupts the structure of dependencies. If you are processing a project/file you just have to make sure to keep the file the request came from and use it's manifest and the browser field before processing the require.

I implemented this in require in this commit for anyone interested

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

No branches or pull requests

2 participants