Add a 'webworker' field for bundler
See original GitHub issueFeature request
What is the expected behavior?
A target of webworker should first look for a webworker field, rather than browser first as it currently is.
What is motivation or use case for adding/changing the behavior?
from: https://webpack.js.org/configuration/resolve/#resolvemainfields When importing from an npm package, … this option will determine which fields in its package.json are checked. The default values will vary based upon the target specified in your webpack configuration. When the target property is set to webworker, web, or left unspecified the following fields are checked in order mainFields: [‘browser’, ‘module’, ‘main’],
some libraries guard usage of keywords like document or window behind bundler fields like browser. This is important for code minification and switching implementation APIs depending on the final environment. There currently is no default field to describe the environment web workers live in. They are mostly the browser environment but without access to DOM apis, which is an important distinction. Trying to using a library that uses DOM apis in a web worker will fail. Currently library authors have no way to specify browser vs webworker difference.
Please see https://github.com/wooorm/parse-entities/issues/19 for a case where this matters. This library uses document.createElement for the browser implementation, and has an alternative field react-native for non-browser API implementation. By default webpack uses the browser field which causes webworkers to bundle incorrectly. There is no way for the library author to fix this, as there is no default webworker field that is tried first when the target is set to webworker. Here is where the library defines it’s two fields to switch implementation depending on the bundler target
How should this be implemented in your opinion?
A new field webworker should be introduced, and checked for before browser when the target webworker is used. Please see https://webpack.js.org/configuration/resolve/#resolvemainfields which documents the current order as browser, then module, then main.
Are you willing to work on this yourself? no, sorry.
Issue Analytics
- State:
- Created 2 years ago
- Comments:25 (13 by maintainers)

Top Related StackOverflow Question
To add: the default in the above referenced package also uses non-browser features. But, when the
browserfield is explicitly requested, then DOM features are used (because it’s much smaller). However, in some cases that doesn’t work, hence thereact-nativeundo of thebrowserfield!EDIT: and, as a maintainer, a solution might also be
conditions. Next to require/import/node/browser, we could advocate for webworker or so (ref: https://nodejs.org/api/packages.html#conditional-exports)Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.