Skip to content

/ workerize-loader

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.

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

@jamesknelson jamesknelson commented 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
Copy link

@jamesknelson jamesknelson commented 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
Copy link
Owner

@developit developit commented 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.
@kpdecker kpdecker linked a pull request that will close this issue Jun 21, 2020
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
Linked pull requests

Successfully merging a pull request may close this issue.

Add support for imported exports
3 participants
@developit @jamesknelson @javamonn
You can’t perform that action at this time.