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.

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

Breaks on latest gatsby, only when there is a webpack cache #131

Open
gersomvg opened this issue Sep 22, 2022 · 5 comments
Open

Breaks on latest gatsby, only when there is a webpack cache #131

gersomvg opened this issue Sep 22, 2022 · 5 comments

Comments

@gersomvg
Copy link

gersomvg commented Sep 22, 2022

It seems like after I start the Gatsby dev server a second time — and webpack has a cache — the worker doesn't load with the exported worker functions set on the object. The moment I clear webpack's cache and restart the dev server, the worker loads fine again.

Does this very limited description by any chance give you a quick insight about what might be causing this?

I'm afraid I can't really give more details, because the inner workings of gatsby/webpack is just one big black box to me.

I can of course make a minimal reproduction with a newly bootstrapped gatsby, if this would be of any help?

@gersomvg
Copy link
Author

Bypassed this issue by using webpack / Workers directly without this loader and RPC implementation. Feel free to investigate further or close this issue if you don't plan to have support for Gatsby out of the box 👍🏻

@rjgotten
Copy link

rjgotten commented Sep 29, 2022

Getting this as well.
Attached a debugger to investigate.

The problem is the loader is not hitting the parser anymore - because there's nothing to parse thanks to the cache; and thus the export declaration hook that is meant to collect exported methods is no longer run.

However, as the output of the loader is marked non-cachable, that part actually will rebuild every time. And ofcourse, after the first build it gets an empty array of collected methods.

The solution here is, I think, to use the Webpack cache to cache the array of exported methods along with the modules. or to somehow mark the entry module of the worker as non-cacheable which forces it to always be processed from source, and always have the parser run.

[EDIT]
Actually: it's even easier than that.
There is no reason to manually bookkeep the exports with the parser hook at all.
Technically, under the assumption that users will only export methods from the entry module of the worker, the only thing you need is:

const exportNames = compilation.moduleGraph.getProvidedExports(entryModule);

@saltenhub
Copy link

saltenhub commented Dec 14, 2022

Running into the same issue with a recent version of create react app (v. 5.0.1). Had to disable the webpack cache as a workaround. Would be great if this could be taken care of on the library side

@ysneo
Copy link

ysneo commented Sep 27, 2023

yes same situation, when I cancel 的 webpack cache, it works fine. So how to make them coexist

@rjgotten
Copy link

rjgotten commented Sep 27, 2023

@ysneo
yes same situation, when I cancel 的 webpack cache, it works fine. So how to make them coexist

There's no way to hot-patch your way through it.
The internals of the plugin have to be rewired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants