Generates a web worker at runtime from webpack's bundled modules with only the used dependencies. Possible because of webpack's module structure. Just require.resolve(PATH_TO_MODULE) the module you want to be the worker's entry point.
inspired by webworkify
npm install webworkify-webpack --saveFor v1 go to: 1.1.8
Version 2 uses webpack's api as much as possible vs the hacky implementation of version 1 (I wasn't aware of webpack's api while writing it) which did the job but with some inconsistency between different browsers and some caveats.
In v2:
- no limitation on webpack's devtool -
evalwas forbidden in v1. - no issues with anonymous functions exported as module.exports - there were issues with anonymous functions in v1.
require.resolveinstead of regularrequire\import- The only limitation is usingrequire.resolvewhich means that currently the code usingwebworkify-webpackis coupled to the build tool (webpack - but who useswebworkify-webpackalready uses webpack) and its not possible to use es2015 modules => checkout out the future work section.
webworkify-webpack vs webpack's worker-loader and target: 'webworker'
webworkify-webpack allows to use one bundle for running same code both on browser and web worker environments.
webpack's current alternatives for web workers are creating bundle which can be run in a web worker environment only and can results in 2 separate files like in the worker-loader case (one file for browser and one for web worker => code duplication).
The motivation for webworkify-webpack was creating a library which expose to the user the same functionality both in sync and async forms.
I wanted to keep one bundle in order to reduce complexity of using external library to the minimum and make bundle size as minimal as possible when using external library which supports both sync and async functionality (without code duplication).
Since webpack's solutions for web workers are being constructed at compile time, the added value is that its possible to use dev tools like hmr (at least when using target: 'webworker') which isn't possible with webworkify-webpack.
In addition, regular js syntax is being used without the need to use require.resolve as in the webworkify-webpack case => checkout out the future work section.
import work from 'webworkify-webpack'Return a new
web worker
from the module at modulePath.
The file at modulePath should export its worker code in module.exports as a
function that will be run with no arguments.
Note that all the code outside of the module.exports function will be run in
the main thread too so don't put any computationally intensive code in that
part. It is necessary for the main code to require() the worker code to fetch
the module reference and load modulePath's dependency graph into the bundle
output.
- all - bundle all the dependencies in the web worker and not only the used ones. can be useful in edge cases that I'm not aware of when the used dependencies aren't being resolved as expected due to the runtime regex checking mechanism or just to avoid additional work at runtime to traverse the dependencies tree.
- bare - the return value will be the blob constructed with the worker's code and not the web worker itself.
First, a main.js file will launch the worker.js and print its output:
import work from 'webworkify-webpack';
let w = work(require.resolve('./worker.js'));
w.addEventListener('message', event => {
console.log(event.data);
});
w.postMessage(4); // send the worker a messagethen worker.js can require() modules of its own. The worker function lives
inside of the module.exports:
import gamma from 'gamma'
module.exports = function worker (self) {
self.addEventListener('message', (event) => {
const startNum = parseInt(event.data); // ev.data=4 from main.js
setInterval(() => {
const r = startNum / Math.random() - 1;
self.postMessage([ startNum, r, gamma(r) ]);
}, 500);
});
};Now after webpackifying this example, the console will contain output from the worker:
[ 4, 0.09162078520553618, 10.421030346237066 ]
[ 4, 2.026562457360466, 1.011522336481017 ]
[ 4, 3.1853125018703716, 2.3887589540750214 ]
[ 4, 5.6989969260510005, 72.40768854476167 ]
[ 4, 8.679491643020487, 20427.19357947782 ]
[ 4, 0.8528139834191428, 1.1098187157762498 ]
[ 4, 8.068322137547542, 5785.928308309402 ]
...
The goal is to make webworkify-webpack fully based on webpack's api. I'm not sure how to accomplish it since I never wrote a webpack loader\plugin (is it possible other way?) so I'm asking for help :)
Points of view:
- webpackBootstrapFunc - should be taken from webpack's source.
- ability to use regular module import\require (not
require.resolve) but still passing the module id to 'webworkify-webpack'. - ability to know all specific's module dependencies in compile time so there is no need to traverse the dependencies tree in runtime with regular expressions (when uglifying the code the web worker's bundle can include more dependencies than only the used ones because regular expressions nature).
- if there is going to be build in compile time, what about hmr as dev tool ?
- is the ability 'webworkify-webpack' provides should be part of webpack core as another form of web workers support or should it remain as external module ?
MIT
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent