npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

r-webworkify-webpack

v2.1.5

Published

launch a web worker at runtime that can require() in the browser with webpack

Downloads

1

Readme

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

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