search

developit / workerize-loader

🏗️ Automatically move a module into a Web Worker (Webpack loader)
https://npm.im/workerize-loader
2.31k stars 86 forks source link

Can't apply plugins to worker #87

Open rjgotten opened 4 years ago

rjgotten commented 4 years ago

Currently there is no way to pass plugins to workerize-loader.

Webpack's documentation is wrong when it states that child compilers inherit all hooks and plugins from the parent compiler. They infact do not inherit plugins at all; they copy over a number of hooks from the parent compiler -- where some plugins may have added them -- to the child compiler.

Several hooks are blacklisted. Banned from this copy process are: make, compile, emit, afterEmit, invalid, done, and thisCompilation. There are ofcourse good reasons not to copy those hooks - as doing so would mess with the control flow for the child compilation and parent compilation. However, it does mean the child compiler has to be fed its own instances of plugins such as the CompressionPlugin which attach to those hooks.

https://github.com/webpack/webpack/blob/498bb0841bd79476569701dc2e4f0f65dc87359c/lib/Compiler.js#L773-L846

This is what the third plugins argument to the createChildCompiler method is for, but having a look at how the child compiler that creates the body of the worker is called:

https://github.com/developit/workerize-loader/blob/2688667adf334e45c69c04ee3bd60f68a455583a/src/index.js#L59

it doesn't link up that third parameter. So right now there is no well-defined way to e.g. apply CompressionPlugin and get Gzip or Brotli compressed workers.

It may still be possible to achieve this by tapping the childCompiler hook on the parent compilation, as it does get passed the created child compiler.

This requires people write their own custom "plugin to apply plugins" - which is well beyond the comfort zone of most Webpack users. (Most webpack users don't write their own plugins. That's something you typically only do if you really; really know what you're doing. )

It's also not exactly trivial to get right, as you'd still also need to filter by the child compiler's name to ensure they're only adding plugins to the correct child compilers created by the workerize-loader and not to e.g. those created by the MiniCssExtractPlugin. Making this worse is the fact that those child compiler names are internal implementation details and not part of any public API, i.e. are subject to change over time.

I.e. this is a short-term workaround at best.

rjgotten commented 4 years ago

[EDIT]

Nevermind; regarding the CompressionPlugin -- the assets from a child compilation are forwarded to the main compiler, so they do become part of being processed by its emit hook eventually. Something else was preventing them from being processed accordingly in my case. (Still trying to figure out what -- but atleast it's not the workerize-loader.)

Still; would it be nice to have configurable plugins for just the worker context?

developit commented 4 years ago

@rjgotten yes, configurable plugins would be nice. I implemented that feature in worker-plugin, and folks seem to use it. The trick with worker-loader is that there isn't really a great place to configure plugins right now - loaders can have config, but not global config, and I think most people are using the loader prefix syntax when using this.

rjgotten commented 4 years ago

@developit The trick with worker-loader is that there isn't really a great place to configure plugins right now - loaders can have config, but not global config, and I think most people are using the loader prefix syntax when using this.

That's actually not that hard to solve with a general purpose InjectOptionsPlugin. It's what I'm currently using to set an environment-specific output name (with or without content hash) for generated loaders.

developit commented 4 years ago

@rjgotten that Gist looks good - want to PR it here? It could be exported as require('workerize-loader').OptionsPlugin.