Latest Results
fix: preserve createRequire().resolve with literal import.meta.url when requireResolve is disabled
When `module.parser.javascript.requireResolve` is `false`, a created require's
`.resolve(...)` is preserved to run at runtime instead of being rewritten to a
module id.
A created require that is used as a real require object — `.resolve(...)`, any
other member (`r.main`, `r.resolve.paths(...)`, ...), or as a bare value
(`helper(r)`, `export { r }`, ...) — is kept and rendered via rspack's injected
`__rspack_createRequire` helper, so the literal `import.meta.url` resolves
relative to the runtime output module and those accesses hit the real require
(instead of a context-require / unsupported-member rewrite). A plain invoke
`r("./x")` is still bundled and `r.cache` still maps to the module cache, so a
created require used only that way is cleared to `undefined` — no dead
`import.meta.url` leaks and CommonJS output stays valid. The keep/clear decision
is deferred to `finish()`.
Since literal `import.meta.url` is only valid in ESM output, an `Unsupported
feature` warning is emitted when a kept `createRequire(import.meta.url)` would
land in a CommonJS bundle. fix: preserve createRequire().resolve with literal import.meta.url when requireResolve is disabled
When `module.parser.javascript.requireResolve` is `false`, a created require's
`.resolve(...)` is preserved to run at runtime instead of being rewritten to a
module id.
A created require that is used as a real require object — `.resolve(...)`, any
other member (`r.main`, `r.resolve.paths(...)`, ...), or as a bare value
(`helper(r)`, `export { r }`, ...) — is kept and rendered via rspack's injected
`__rspack_createRequire` helper, so the literal `import.meta.url` resolves
relative to the runtime output module and those accesses hit the real require
(instead of a context-require / unsupported-member rewrite). A plain invoke
`r("./x")` is still bundled and `r.cache` still maps to the module cache, so a
created require used only that way is cleared to `undefined` — no dead
`import.meta.url` leaks and CommonJS output stays valid. The keep/clear decision
is deferred to `finish()`.
Since literal `import.meta.url` is only valid in ESM output, an `Unsupported
feature` warning is emitted when a kept `createRequire(import.meta.url)` would
land in a CommonJS bundle. fix: preserve createRequire().resolve with literal import.meta.url when requireResolve is disabled
When `module.parser.javascript.requireResolve` is `false`, a created require's
`.resolve(...)` is preserved to run at runtime instead of being rewritten to a
module id.
A created require that is used as a real require object — `.resolve(...)`, any
other member (`r.main`, `r.resolve.paths(...)`, ...), or as a bare value
(`helper(r)`, `export { r }`, ...) — is kept and rendered via rspack's injected
`__rspack_createRequire` helper, so the literal `import.meta.url` resolves
relative to the runtime output module and those accesses hit the real require
(instead of a context-require / unsupported-member rewrite). A plain invoke
`r("./x")` is still bundled and `r.cache` still maps to the module cache, so a
created require used only that way is cleared to `undefined` — no dead
`import.meta.url` leaks and CommonJS output stays valid. The keep/clear decision
is deferred to `finish()`.
Since literal `import.meta.url` is only valid in ESM output, an `Unsupported
feature` warning is emitted when a kept `createRequire(import.meta.url)` would
land in a CommonJS bundle. Latest Branches
0%
+2%
refactor-rspack-source-ache 0%
ci/sccache-tos-self-hosted © 2026 CodSpeed Technology