fix: decouple init & module error handling from runtime module#868
fix: decouple init & module error handling from runtime module#868
Conversation
🦋 Changeset detectedLatest commit: cc9dfbc The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
packages/repack/src/plugins/RepackTargetPlugin/InitRuntimeModule.ts
Outdated
Show resolved
Hide resolved
thymikee
left a comment
There was a problem hiding this comment.
Looks like a solid improvement with less hacks. Any ideas how you could test it?
I would just stick to existing integration tests that we have - this is a very internal change. The easiest way to test it in an additional way would be to compile a bundle and verify that the modules get injected properly. |
|
I needed to make the runtime module classes dynamic to deal with the compatibility between webpack and rspack, all works good now on both platforms 👍 |
Summary
partial solution to #866
In some cases
loadScriptruntime module might not get injected into the bundle. Since all of the logic for Repack runtime lives there, it might cause undefined behaviour like failing to process EarlyJS errors or failure to initialise Repack global object.This PR separates the
loadScriptpart into it's own runtime module, and makesinitandmoduleErrorHandlerparts separate runtime modules.Previously in Rspack there was no way to add runtime modules - we could only edit existing ones and we were forced to concatenate init & load script modules into one. This is no longer the case so we can split them into separate entities.
The types injected into the global scope were also reworked - now most types are hidden behind a
RepackRuntimeGlobalsnamespace to prevent polluting the global typescript scopeTest plan