refactor: inline __toDynamicImportESM #7747
Conversation
How to use the Graphite Merge QueueAdd the label graphite: merge-when-ready to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
✅ Deploy Preview for rolldown-rs canceled.
|
842410e to
04c0010
Compare
There was a problem hiding this comment.
Pull request overview
This PR refactors the __toDynamicImportESM runtime helper by inlining its implementation directly at call sites. This optimization solves an issue where unused runtime helpers may be included in chunks when CommonJS modules are dynamically imported, particularly when chunk optimization happens after the linking stage.
Key Changes:
- Removed
__toDynamicImportESMfrom the base runtime helpers and inlined its logic (__toESM(m.default, isNodeMode)) at call sites - Reduced runtime helper count from 20 to 19 and adjusted bit flags accordingly
- Updated code generation to emit arrow functions for dynamic imports:
.then((m) => __toESM(m.default))
Reviewed changes
Copilot reviewed 16 out of 17 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
crates/rolldown/src/runtime/runtime-base.js |
Removed __toDynamicImportESM export and associated formatting cleanup |
crates/rolldown_common/src/generated/runtime_helper.rs |
Removed ToDynamicImportEsm flag, adjusted bit positions, and updated helper count from 20 to 19 |
crates/rolldown/src/stages/link_stage/reference_needed_symbols.rs |
Updated to reference ToEsm helper instead of ToDynamicImportEsm for CommonJS dynamic imports |
crates/rolldown/src/module_finalizers/mod.rs |
Inlined __toDynamicImportESM logic in two places: ESM format (arrow function) and CJS format (wrapped in Promise) |
crates/rolldown_plugin_hmr/src/runtime/runtime-extra-dev-common.js |
Kept __toDynamicImportESM as inline method for HMR runtime, calling __toESM(mod.default, isNodeMode) |
| Various test snapshots | Updated expected outputs to reflect inlined transformation and resulting hash changes |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
c8096f0 to
2d67725
Compare
2d67725 to
1fca581
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 16 out of 17 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Benchmarks Rust |
1fca581 to
82b4c05
Compare
82b4c05 to
6d80943
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 16 out of 17 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@sapphi-red cc |
Merge activity
|
I found an issue while trying to solve #4905. Here is an example https://github.com/rolldown/rolldown/pull/7742/changes#diff-627d2ba1517f46e8cfe17e7ce9efe06e8b51f83a3c3ff87586c415981e3e5bc3. When a module dynamically imports a CommonJS module, we always generate code like: ```js import("./foo.js").then(__toDynamicImportESM()).then(({ default: { bar: b } }) => {}) ``` But after implementing the #4905 optimization, when the importer and the importee are in the same chunk, we generate code like: ```js Promise.resolve().then(() => __toESM(require_foo())).then(mod) => { console.log(mod); }); ``` Since the chunk optimization happens after linking state, we should reference both `__toDynamicImportESM` and `__toESM` runtime helpers. If the runtime module is included in a different chunk, one of `__toESM` and `__toDynamicImportESM` may not be used but is still included with the `import` statement, which can't be eliminated by the minifier. Inlining `__toDynamicImportESM` could solve this issue. ### Pros 1. Resolves the issue mentioned above. 2. Improves run-time performance a little. 3. Reduces the overall size of the runtime modules. ### Cons 1. Increases the generated output size a little. `m.default` can't be compressed by the minifier. I am open to both solution.
6d80943 to
6c69f39
Compare
## [1.0.0-beta.59] - 2026-01-07 ⚡ Inline Dynamic Imports for Statically Imported Modules - When a module is already statically imported, dynamic imports to that same module are now inlined instead of creating a separate chunk ### 🚀 Features - plugin_timings: add 3s threshold and doc link to warning message (#7741) by @shulaoda - improve treeshaking logic to handle empty parameter list in dynamic import .then() callbacks (#7781) by @Copilot - dev/lazy: don't include already executed modules (#7745) by @hyf0 - dev/lazy: support dynamic `import(..)` (#7726) by @hyf0 - inline dynamic imports that imports statically imported modules (#7742) by @IWANABETHATGUY - option: add experimental option to control chunk optimization (#7738) by @IWANABETHATGUY ### 🐛 Bug Fixes - inline dynamic entry to user defined entry with esm wrap kind (#7783) by @IWANABETHATGUY - use canonical namespace reference for property access (#7777) by @IWANABETHATGUY - dynamic entry merged into common chunk with cjs and esm wrap kind (#7771) by @IWANABETHATGUY - tla: should not await non-tla-related modules (#7768) by @hyf0 - dynamic entry captured by common chunk with CJS format (#7757) by @IWANABETHATGUY - module_loader: mark emitted chunks as user-defined entry when already loaded (#7765) by @shulaoda - normalize preserveModulesRoot path (#7737) by @IWANABETHATGUY - linker: resolve race condition in side effects computation for export-star (#7728) by @camc314 ### 🚜 Refactor - plugin_timings: filter out plugins with duration < 1s from timing warnings (#7785) by @shulaoda - module_loader: remove unnecessary collect before extend (#7769) by @shulaoda - rename _id suffixes to _idx for oxc_index types (#7767) by @IWANABETHATGUY - remove duplicate `preserve_entry_signatures` from `AddEntryModuleMsg` (#7762) by @shulaoda - module_loader: pass `user_defined_entries` by reference (#7756) by @shulaoda - dev/lazy: get proxy entry's `ResolvedId` correctly (#7746) by @hyf0 - simplify try_rewrite_import_expression control flow (#7753) by @IWANABETHATGUY - module_loader: remove unnecessary dynamic import handling for runtime module (#7754) by @shulaoda - inline __toDynamicImportESM (#7747) by @IWANABETHATGUY - use From impl for ModuleLoaderOutput conversion (#7732) by @shulaoda - remove duplicate fields from `ModuleLoader` (#7731) by @shulaoda - tweak `resolve_user_defined_entries` (#7727) by @shulaoda ### 📚 Documentation - add rolldown-string reference to native MagicString compatibility section (#7778) by @Copilot - improve comments for export star side effects handling (#7730) by @IWANABETHATGUY ### 🧪 Testing - use assertion instead of console.log for some testcase (#7744) by @IWANABETHATGUY ### ⚙️ Miscellaneous Tasks - tweak some `output.dynamicImportInCjs` related rollup test results (#7776) by @sapphi-red - mark esbuild/dce/dce_of_symbol_ctor_call as passed (#7775) by @sapphi-red - deps: update oxc apps (#7772) by @renovate[bot] - vite-tests: allow running on PRs with `test: vite-tests` label (#7770) by @shulaoda - deps: update oxc apps (#7760) by @renovate[bot] - deps: update rollup submodule for tests to v4.55.1 (#7763) by @sapphi-red - deps: update test262 submodule for tests (#7764) by @sapphi-red - deps: update oxc to v0.107.0 (#7758) by @camc314 - deps: update taiki-e/install-action action to v2.65.13 (#7751) by @renovate[bot] - deps: update rust crates (#7750) by @renovate[bot] - deps: update npm packages (#7749) by @renovate[bot] - deps: update github-actions (#7748) by @renovate[bot] - deps: update dependency oxlint-tsgolint to v0.10.1 (#7729) by @renovate[bot] - deps: update crate-ci/typos action to v1.41.0 (#7725) by @renovate[bot] Co-authored-by: shulaoda <[email protected]>

I found an issue while trying to solve #4905. Here is an example https://github.com/rolldown/rolldown/pull/7742/changes#diff-627d2ba1517f46e8cfe17e7ce9efe06e8b51f83a3c3ff87586c415981e3e5bc3. When a module dynamically imports a CommonJS module, we always generate code like:
But after implementing the #4905 optimization, when the importer and the importee are in the same chunk, we generate code like:
Since the chunk optimization happens after linking state, we should reference both
__toDynamicImportESMand__toESMruntime helpers. If the runtime module is included in a different chunk,one of
__toESMand__toDynamicImportESMmay not be used but is still included with theimportstatement, which can't be eliminated by the minifier.Inlining
__toDynamicImportESMcould solve this issue.Pros
Cons
m.defaultcan't be compressed by the minifier.I am open to both solution.