-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
Implement all path variables for webworker dynamic imports #7581
Conversation
For maintainers only:
|
As I mention above, I have a few questions about my test. I added a test under ConfigTestCases to verify that all documented path variables compile without exception when using dynamic imports and targeting web, webworker, node, or async-node. As is, my test just verifies that compilation doesn't throw and skips test execution with So mainly I'm wondering: Would you see the fuller test as valuable? If so, can we discuss ways to resolve the friction I ran into? Thanks! |
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
Oh, one more thought: It looks like there's an opportunity to re-use the code for formatting the dynamic import's path. I see 4 copies of it currently. It looks straightforward to add a method on MainTemplate like Template.ident([
"importScript(" +
mainTemplate.getDynamicImportPathExpr(chunk, "chunkId") +
");"
]) Does that seem like a good approach? If so, I'm happy to amend this PR or create a new one. Thanks! |
Hi @TimHambourger. Just a little hint from a friendly bot about the best practice when submitting pull requests:
You don't have to change it for this PR, just make sure to follow this hint the next time you submit a PR. |
Thanks |
Previously, not all path variables were implemented when doing dynamic imports and targeting webworker. See #7563.
What kind of change does this PR introduce?
A bugfix. WebWorkerMainTemplatePlugin.js was missing some required chunk attributes.
Did you add tests for your changes?
Yes. Though I do have questions about the test framework. I'll post those as a separate comment.
Does this PR introduce a breaking change?
No. Prior to this commit, unsupported path variables would either throw at compile time or produce unexpected import paths at runtime.
What needs to be documented once your changes are merged?
No new documentation needed.