Repository navigation
Support for export specifiers? #15
Description
It appears like workerize-loader only supports moving export declarations in the target module into a worker. I'm attempting to use it with Bucklescript, which compiles modules down to an export specifier list, i.e. export { foo, bar, } instead of export declarations.
I took a pass at implementing this and couldn't get around Webpack declaring its own parser plugin and bailing on export specifier, I think for tree-shaking purposes. I don't have much experience with Webpack plugins though and it seems like there should be a way to get this to work. Are there any alternate approaches you can suggest, or maybe workarounds?
One other thought I had for my purposes would be to instead compile to commonjs and tweak workerize so that it would accept the pre-compiled source instead of doing the current find-and-replace compilation step.
Activity
developit commentedon Jan 24, 2018
Yup, as best I can tell this is a bug in Webpack's parser API :(
FWIW I think it would actually be better to switch from static analysis to having the worker postMessage() up its exported keys on init. This means a breaking version change since it will make worker instantiation asynchronous, but it would add support for reexports and export declarations.
jamesknelson commentedon Nov 1, 2018
This would be really handy, as rollup also exports things via export specifiers -- so any module that is built with rollup is going to be unusable as a worker as-is :-(
jamesknelson commentedon Nov 1, 2018
I've managed to solve this issue for my use case with ES6 Proxies. I've published a fork if anybody needs it: https://github.com/jamesknelson/workerize-proxy-loader
developit commentedon Feb 21, 2020
For passers-by: if anyone has an interest in adding support for CommonJS export parsing, I'd be happy to review and merge a PR for it.