question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Add a 'webworker' field for bundler

See original GitHub issue

Feature 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:open
  • Created 2 years ago
  • Comments:25 (13 by maintainers)

github_iconTop GitHub Comments

1reaction
wooormcommented, Nov 8, 2021

To add: the default in the above referenced package also uses non-browser features. But, when the browser field is explicitly requested, then DOM features are used (because it’s much smaller). However, in some cases that doesn’t work, hence the react-native undo of the browser field!

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)

0reactions
webpack-botcommented, Jul 9, 2022

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Web Workers: Bundle shared dependencies only once #16001
If you currently add a web worker to Angular (e.g. via ng generate webWorker ) and use the same dependency on the main...
Read more >
module web worker workaround - javascript - Stack Overflow
So I decided to run them in the web worker. Since the logic for the computation is already written in JavaScript modules and...
Read more >
Multithreading in JavaScript with Web Workers - LeanyLabs
Most modern web applications use WebPack to bundle all the javascript into one or multiple bundles. Since Web Worker code has to be...
Read more >
Comlink and web workers: A match made in heaven
Comlink is a relatively new JavaScript library that makes working with web workers as intuitive as simply calling functions.
Read more >
Using Web Workers - Web APIs - MDN Web Docs
The error event has the following three fields that are of interest: ... Next, we add an onmessage handler on the port to...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found