Breaks on latest gatsby, only when there is a webpack cache about workerize-loader HOT 5 OPEN

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

from workerize-loader.

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

from workerize-loader.

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

from workerize-loader.

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

from workerize-loader.

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

from workerize-loader.