webworkify-webpack

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

install

npm install webworkify-webpack --save

v3 vs v2

Update the bootstrap code to work with the webpack v5 version. Credit to: https://github.com/borisirota/webworkify-webpack/pull/44, wupeng-engineer, for what this is based on.

This is mainly just that, updated and tested to work with hls.js, as support for this was blocking upgrading to webpack v5 as the built-in support in Webpack doesn't allow an "inline-worker", the Blob workflow. And the worker-loader plugin with v5 has you manually produce a second asset that is embedded, which increases the bundle size.

The approach here still seems to be the best available, but does require a more future error-prone integration.

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.

In v2:

• no limitation on webpack's devtool - eval was forbidden in v1.
• no issues with anonymous functions exported as module.exports - there were issues with anonymous functions in v1.
• require.resolve instead of regular require\import - The only limitation is using require.resolve which means that currently the code using webworkify-webpack is coupled to the build tool (webpack - but who uses webworkify-webpack already 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.

methods

import work from 'webworkify-webpack'

let w = work(require.resolve(modulePath) [, options])

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.

options

• 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.

example

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 message

then 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 ]
...

future work

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:

1. webpackBootstrapFunc - should be taken from webpack's source.
2. ability to use regular module import\require (not require.resolve) but still passing the module id to 'webworkify-webpack'.
3. 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).
4. if there is going to be build in compile time, what about hmr as dev tool ?
5. 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 ?

license

MIT