Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for export specifiers? #15

Open
javamonn opened this issue Jan 23, 2018 · 4 comments · May be fixed by #100
Open

Support for export specifiers? #15

javamonn opened this issue Jan 23, 2018 · 4 comments · May be fixed by #100

Comments

@javamonn
Copy link

javamonn commented Jan 23, 2018 •
edited

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.
@developit
Copy link
Owner

developit commented Jan 24, 2018 •
edited

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
Copy link

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
Copy link

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
Copy link
Owner

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.

@kpdecker kpdecker linked a pull request Jun 21, 2020 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add support for imported exports kpdecker/workerize-loader
3 participants
@developit @jamesknelson @javamonn