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 --save
v2 vs v1
For 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.
- 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 regular
require\import- The only limitation is using
require.resolvewhich means that currently the code using
webworkify-webpackis coupled to the build tool (webpack - but who uses
webworkify-webpackalready uses webpack) and its not possible to use es2015 modules => checkout out the future work section.
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
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.
let w = work(require.resolve(modulePath) [, options])
Return a new
from the module at
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
- 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.
main.js file will launch the
worker.js and print its output:
;let w = ;w;w; // send the worker a message
require() modules of its own. The worker function lives
inside of the
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 ?