thread-loader
thread-loader copied to clipboard
webpack-contrib
serialization?
Stumbled on it by noticing that my regex's were failing, but raises a larger issue:
There are plenty of non-JSON values used in loader options that currently break when using thread-loader (regex, dates, functions). It seems like an easy solution would be to use a more comprehensive serialization method, or allow users to plug their own in. This will allow thread-loader to work with even more loaders and seems like a quick win.
I think this is the line in question: https://github.com/webpack-contrib/thread-loader/blob/b02d50367564fc81e8d5f28bfcfc7807831f7759/src/WorkerPool.js#L101
Quick glance shows a few libraries that handle this, I'm sure you could either do this internally or find a better one as well:
- https://github.com/goodseller/qjson#readme
- https://github.com/vkiryukhin/jsonfn#readme
Presumably the right fix is to use the dedicated Node API for complex object serialization:
https://nodejs.org/api/v8.html#v8_serialization_api
@arcanis I think that solution would work well for almost every case - serializing functions isn't a thing and I think it will just need to be noted in the docs + have a nice error message that it isn't supported. I do see functions used in loader configs relatively frequently.
@yocontra I'm sorry to tag you directly. Could you clarify whether the current README is out of date? Specifically, the third rule in below. I want to make sure that each worker will read the options I provided for those loaders, e.g. babel-loader.
Loaders running in a worker pool are limited. Examples:
Loaders cannot emit files. Loaders cannot use custom loader API (i. e. by plugins). Loaders cannot access the webpack options.
I also opened a question there, if you could help I will be very grateful: https://github.com/webpack/webpack/discussions/18196.
