Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Web Worker support #13700
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
Web Worker support #13700
Changes from all commits
d9249c9
cf3171f
224cbe1
ced9890
f294851
4c92bad
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@developit figured out the rebuild issue. It's because the worker changes name on rebuilds. Is this intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also seeing a weird behaviour where sometimes the child compilation picks up on changed files, and sometimes it doesn't.
In this test I have seen all these outputs just by running the rebuild test repeatedly with no code changes:
src/app/dep.ts
twice and registers the change frombar
tobaz
,baz
ends up in0.worker.js
baz
ends up in1.worker.js
0.worker.js
nor1.worker.js
containbaz
Do you have any idea of what's happening here? Is there some cache inside
worker-plugin
that might be acting strange?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the worker changing names may be somewhat unavoidable. There's a
filename
option that would make it possible to use a static name, but that doesn't seem like the right solution here either.There's no caching enabled in worker-plugin, so it's likely something deeper in Webpack.
I'm going to add some rebuild tests to the plugin to see if I can trigger this in isolation. My hunch is that the parser hook's instance counter isn't being reset because the parser is reused across webpack compilations. It would certainly explain the
0
-->1
bug there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Been trying to debug further and have some findings.
In our test suite we run webpack several times in the same thread. I think the test order affects the result of rebuilds with
worker-plugin
.To test this I added a lot of debug logs and tried running the basic test and the rebuild test in different orders. Then I collected the logs just from the rebuild test.
One of the things I logged was the entry for the child compilation: https://github.com/GoogleChromeLabs/worker-plugin/blob/7ea61fb83a02170d0235e4590c4deb617874e70a/src/loader.js#L77. The others were build count, changed file being loaded, and which bundle contains the changed content.
If I run the rebuild test first and the basic test second I see:
dep.ts
is loaded withbar
0.worker.js
dep.ts
is loaded withbaz
1.worker.js
0.worker.js
does not containsbaz
1.worker.js
containsbaz
If I run the rebuild test first and the basic test second I see:
dep.ts
is loaded withbar
0.worker.js
1.worker.js
dep.ts
is loaded withbaz
0.worker.js
0.worker.js
containsbaz
1.worker.js
does not containsbaz
So the end result is that the order of the tests seems to affect which bundle ends up containing the changed code.
But more interestingly, when the rebuild test is second, before the first build finishes there are a total of two child compilations that run. That part I find rather odd. I don't understand why that would happen. Even weirder is that the next child compilation is again the
0
one.