Save the exported method names in a local cache object #61
Conversation
…e, instead of using the compilation object. Fixes developit#24 where worker methods are undefined after a recompile.
| @@ -83,7 +83,7 @@ loader.pitch = function(request) { | |||
| // only process entry exports | |||
| if (current.resource!==entry) return; | |||
|
|
|||
| let exports = compilation.__workerizeExports || (compilation.__workerizeExports = {}); | |||
| let exports = CACHE[entry] || (CACHE[entry] = {}); | |||
There was a problem hiding this comment.
The core issue is here. The __workerizeExports property does not seem to be persisted across re-compiles, resulting in an empty methods list. I propose using the CACHE object instead, since it seems to be used for this purpose anyway.
I assume the compilation object is somehow instanced by entry file, so I wanted to replicate that in the CACHE object if there are many workers in the project.
I think this will still require the end-user to restart the build when method names change, but that's a lot better than having to restart after any change. AFAIK the generated filename isn't available at this point yet, and this function only runs once so it wouldn't know what the next filename is after a recompile. Feel free to suggest modifications to this to enable recompiling method name changes without a restart.
| @@ -106,8 +106,9 @@ loader.pitch = function(request) { | |||
| if (entries[0]) { | |||
| worker.file = entries[0].files[0]; | |||
|
|
|||
| let entry = entries[0].entryModule.resource; | |||
There was a problem hiding this comment.
The CACHE is keyed by the resource name, so we need to retrieve that here.
|
Apologies for the long lead time on this PR. I've been pondering how to do this without relying on static exports. It might be some combination of this and inspecting |
|
@danieldunderfelt @developit is this PR still active? We're having the issue mentioned in #24 and wanted to know if this is going to be solved soon, or if we should fork the package (essentially merging this PR)/move to another one for web workers in Webpack? |
|
Any updates on this @developit @danieldunderfelt ? |
|
@exarus I don't know, it is in the hands of @developit. I'm not actively using this package at the moment. I recommend patch-package if you need to hotpatch a dependency. |
|
Thanks @danieldunderfelt. I created a patch for this, available here if anyone wants to use it until this PR is merged. |
|
@developit Thanks for merging this. Is a new version of |
@developit Is a v1.1.1 (or otherwise) coming with this? It's been over 2 months since this PR was merged to |
|
Hi @bengry - sorry about that, I'll get a release out today. |
|
Published in 1.2.0. |
|
Thanks. Seems like it raised another issue for people though - #85. |
Save the exported method names in a local cache object, per entry file, instead of using the compilation object. Fixes #24 where worker methods are undefined after a recompile.
Since this is the first webpack loader I've touched, this PR might need further changes. But using the CACHE object like this works, as opposed to using the compilation object which doesn't work after a recompile.
This PR is meant to illustrate the problem, there might be a better way to fix it.