Merging this PR will not alter performance

✅ 4 untouched benchmarks
⏩ 10 skipped benchmarks¹

_{Comparing AlonMiz:fix/chunk-optimizer-precise-cycle-detection (99b615b) with main (d9be119)²}

Open in StackBlitz

npm i https://pkg.pr.new/@rolldown/browser@9049

npm i https://pkg.pr.new/@rolldown/debug@9049

npm i https://pkg.pr.new/@rolldown/pluginutils@9049

npm i https://pkg.pr.new/rolldown@9049

npm i https://pkg.pr.new/@rolldown/binding-android-arm64@9049

npm i https://pkg.pr.new/@rolldown/binding-darwin-arm64@9049

npm i https://pkg.pr.new/@rolldown/binding-darwin-x64@9049

npm i https://pkg.pr.new/@rolldown/binding-freebsd-x64@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-arm-gnueabihf@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-arm64-gnu@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-arm64-musl@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-ppc64-gnu@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-s390x-gnu@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-x64-gnu@9049

npm i https://pkg.pr.new/@rolldown/binding-linux-x64-musl@9049

npm i https://pkg.pr.new/@rolldown/binding-openharmony-arm64@9049

npm i https://pkg.pr.new/@rolldown/binding-wasm32-wasi@9049

npm i https://pkg.pr.new/@rolldown/binding-win32-arm64-msvc@9049

npm i https://pkg.pr.new/@rolldown/binding-win32-x64-msvc@9049

commit: ff7d744

trying to add some tests... will update soon 🙏

I've added a tests to show the reproduction case 🙏

I am sorry, but the main branch produces identical results to this branch. We at least need a reproduction to verify the effectiveness of the issue-fixing PR.

@IWANABETHATGUY Thanks for looking at this! I've added 5 unit tests that directly demonstrate the false positive in would_create_circular_dependency.

The key test is test_no_false_positive_when_source_has_deps:

Chunk graph:
  0 (target/entry) -> deps: {1, 2}
  1 (common/source) -> deps: {2}
  2 (common/lib) -> deps: {}

Merging chunk 1 into chunk 0 is safe — no cycle would be created.

Old algorithm (BFS from source.deps ∪ target.deps with simulation):

1. BFS seeds: {2} ∪ {1, 2} = {1, 2}
2. Visit chunk 1: 1.deps.contains(source=1)? → YES → queue target(0)
3. Visit chunk 0: found target → FALSE POSITIVE ❌

New algorithm (source has deps → BFS from source.deps only):

1. BFS seeds: {2}
2. Visit chunk 2: deps={}. Not target → no cycle → CORRECT ✅

The integration test (issues/9049/) doesn't show a difference because the chunk optimizer's try_insert_into_existing_chunk only merges under specific conditions (single-entry reference, entry chunk kind, etc.) that are hard to trigger with a small test. But the unit tests prove the algorithm difference directly.

You can run them with:

cargo test -p rolldown --lib -- chunk_optimizer::tests

@IWANABETHATGUY Thanks for looking at this! I've added 5 unit tests that directly demonstrate the false positive in would_create_circular_dependency.

The key test is test_no_false_positive_when_source_has_deps:

Chunk graph:
  0 (target/entry) -> deps: {1, 2}
  1 (common/source) -> deps: {2}
  2 (common/lib) -> deps: {}

Merging chunk 1 into chunk 0 is safe — no cycle would be created.

Old algorithm (BFS from source.deps ∪ target.deps with simulation):

1. BFS seeds: {2} ∪ {1, 2} = {1, 2}
2. Visit chunk 1: 1.deps.contains(source=1)? → YES → queue target(0)
3. Visit chunk 0: found target → FALSE POSITIVE ❌

New algorithm (source has deps → BFS from source.deps only):

1. BFS seeds: {2}
2. Visit chunk 2: deps={}. Not target → no cycle → CORRECT ✅

The integration test (issues/9049/) doesn't show a difference because the chunk optimizer's try_insert_into_existing_chunk only merges under specific conditions (single-entry reference, entry chunk kind, etc.) that are hard to trigger with a small test. But the unit tests prove the algorithm difference directly.

You can run them with:

cargo test -p rolldown --lib -- chunk_optimizer::tests

That did not make much sense. I also let Claude generate a counter-example with a unit test. We need an integration test. I will try another project and create a minimal reproduction first.

That did not make much sense. I also let Claude generate a counter-example with a unit test. We need an integration test. I will try another project and create a minimal reproduction first.

im working on a reproduction as well 🙏 hope to update soon

@IWANABETHATGUY I've been trying to create a minimal bundler-level reproduction, but the false positive only triggers in Angular applications built with Vite. Simple JS module graphs don't create the specific chunk dependency topology needed.

The reason: Angular's compiled output creates complex implicit dependency chains through dependency injection, decorators, and component metadata. These create a dense module dependency graph where calc_chunk_dependencies produces chunk-level dependencies that trigger the false positive in would_create_circular_dependency.

The unit tests I added directly prove the algorithm bug — test_no_false_positive_when_source_has_deps shows a chunk graph where the old algorithm returns true (false positive) but should return false.

I'm working on creating an Angular + Vite reproduction project with lazy routes that demonstrates the chunk count difference. Will update soon.

Debug Output from Production App

I've added debug logging to the original algorithm and built against our production Angular app. Here's the actual data:

[BLOCKED] source=1232 (deps=[1229]), target=0 (deps=[2215, 1485, 1334, ...300+ deps])
[BLOCKED] source=1231 (deps=[1242, 1249, 1234, 1230, ...10 deps]), target=0 (deps=[...300+ deps])
[CHUNK_OPT] total blocked: 1046

Key observations:

• ALL 1,046 blocked merges target chunk 0 (the main entry chunk)
• Chunk 0 has 300+ dependencies (it's the Angular app's main entry)
• Source chunks have small dep lists (1-10 deps)
• The false positive occurs because BFS from target.deps (300+ chunks) inevitably reaches a chunk that depends on source, triggering the simulation

Why simple reproductions don't work:
The false positive requires the target chunk to have hundreds of dependencies. This only happens in large applications where the main entry transitively depends on many modules. In simple test projects, the main entry has few dependencies, so the BFS from target.deps doesn't reach enough chunks to trigger the false positive.

The false positive is also cascading — early merges via merge_chunk_dependencies add more deps to the target chunk, making subsequent merges more likely to trigger false positives.

The unit tests directly prove the algorithm bug with a crafted chunk graph that has the same topology:

• Source with deps {A}
• Target with deps {source, A}
• Old algorithm: BFS from {A, source, A}, visits source, source.deps.contains(source) → YES → queue target → FOUND → false positive
• New algorithm: source has deps → BFS from source.deps only {A}, visits A, A has no deps → no cycle → correct

I understand you need a bundler-level reproduction, but the false positive only manifests in apps with 2000+ entry points where the main entry accumulates 300+ chunk dependencies. I've tried 10+ different reproduction approaches (simple JS, Angular + Vite, virtual modules, 500 entries) and none trigger it because the chunk optimizer merges everything before the dependency graph becomes complex enough.

Would you be open to reviewing the unit tests as the proof, or would you prefer I provide access to our production build logs?

Debug Output from Production App

I've added debug logging to the original algorithm and built against our production Angular app. Here's the actual data:

[BLOCKED] source=1232 (deps=[1229]), target=0 (deps=[2215, 1485, 1334, ...300+ deps])
[BLOCKED] source=1231 (deps=[1242, 1249, 1234, 1230, ...10 deps]), target=0 (deps=[...300+ deps])
[CHUNK_OPT] total blocked: 1046

Key observations:

• ALL 1,046 blocked merges target chunk 0 (the main entry chunk)
• Chunk 0 has 300+ dependencies (it's the Angular app's main entry)
• Source chunks have small dep lists (1-10 deps)
• The false positive occurs because BFS from target.deps (300+ chunks) inevitably reaches a chunk that depends on source, triggering the simulation

Why simple reproductions don't work: The false positive requires the target chunk to have hundreds of dependencies. This only happens in large applications where the main entry transitively depends on many modules. In simple test projects, the main entry has few dependencies, so the BFS from target.deps doesn't reach enough chunks to trigger the false positive.

The false positive is also cascading — early merges via merge_chunk_dependencies add more deps to the target chunk, making subsequent merges more likely to trigger false positives.

The unit tests directly prove the algorithm bug with a crafted chunk graph that has the same topology:

• Source with deps {A}
• Target with deps {source, A}
• Old algorithm: BFS from {A, source, A}, visits source, source.deps.contains(source) → YES → queue target → FOUND → false positive
• New algorithm: source has deps → BFS from source.deps only {A}, visits A, A has no deps → no cycle → correct

I understand you need a bundler-level reproduction, but the false positive only manifests in apps with 2000+ entry points where the main entry accumulates 300+ chunk dependencies. I've tried 10+ different reproduction approaches (simple JS, Angular + Vite, virtual modules, 500 entries) and none trigger it because the chunk optimizer merges everything before the dependency graph becomes complex enough.

Would you be open to reviewing the unit tests as the proof, or would you prefer I provide access to our production build logs?

I will do it by myself.

Reproduction

I created a minimal reproduction: https://github.com/AlonMiz/rolldown-9049-repro

Setup

git clone https://github.com/AlonMiz/rolldown-9049-repro.git
cd rolldown-9049-repro
npm install rolldown@latest
node generate.mjs
node build.mjs

Results

The project has 1 main entry that dynamically imports 200 route modules. Routes share 50 services and 20 utilities with overlapping dependencies. The chunk optimizer should merge shared modules into existing entry chunks, but #8371's overly-conservative circular dependency check blocks legitimate merges.

Run bash compare.sh to reproduce the version comparison automatically.

cc @brandonroberts — this regression from #8371 likely affects Analog and other Angular/Vite projects with many lazy-loaded routes. The overly-conservative cycle detection in the chunk optimizer blocks legitimate merges, creating extra common chunks. Would be great to get your input on this.

https://repl.rolldown.rs/#eNqVVcFymzAQ/ZUdLsDEkdGhF2fcS+69ZKaX4AMFESsFySMJ1x3Cv1crAcFAmvhiI61Wu++93VUblMGuDbTKt43hlXa/lLxq3BXBbs2yCXJrYJeTVAZyKbSBc1ZR2EPY0PAhFb2pbERuuBRQChpdYmhBMdMoARe4cx4P0KUi6DaBklVVyD+C2NtK/jIJv2Lx4XntYrRQsJIL9ujM0EGpZA3h4IbZjPnYk1lTuf/RI2pTAcDFqTE78HeSmpmMuK1UdLG9AVNEHjRTZ54zvdXnPJlxtLDN0rR4k41lIhlzJGRCLLpgstPzFM/T9fMoxBrVGD0qJlzbiLi+g3AX2l+Uoogd8VcCPv18TFBAneCta4DnRbGwLQF/BcCtBK0ARkRTwG79DhjxrwJ2FatdxQ6A64yLGc5hawYPiX7PdCH/FTTM8YOzAw2p2G7hiRcMWFmy3ICRcFLszIT9VIzd62P2m4uXVBQyb2q7TQw3FbMQnp3mIQ/jjWcDPw/kVXIRhSHWbyo8ZiUbw7R1aTu761fPoUrCg92LYth/71sgsll6s/9ziPCm0Yd+6uOQLaL/yGrMuZJ5hvKRY6aPRFeWjojG8PZmW9dVIC8h6oONfgerMnbrYj+KiTkyEdWYjZ0IA0O/ZPGXGHYxttcNMrmHmigmCqYiLAnMDifQJmDBzqiG9VUwhz4th4Xtv3VxU2GsV8ZVQ902DAaoPW2+P3y1WJaxR3y99As3kj0jPRHX7bf+JExImD8JbqI0Ts/lk5CsPQnJ+CTMuZ6Pn4VtqcPXqb1JNAfsphn1kQ5IPR10QFH8wvHQ62CZOFtYlCQkuVc5od+C7h+BHpFP

This is the minimum reproduction I found, can you clean the pr and add this integration test?

Done! I've cleaned the PR:

• Rebased on latest main
• Squashed into a single commit
• Replaced the integration test with your minimal reproduction (main + 2 routes + 2 services + 2 utils with dynamic imports)
• Test asserts 3 chunks (rc.4 behavior) — without the fix, it produces 4 chunks (extra common chunk)

Verified locally:

• 5 unit tests pass ✅
• has_side_effects field added to test helper (new field from upstream)
• Reproduction confirmed: rc.4 → 3 chunks, rc.15 → 4 chunks

✅ Deploy Preview for rolldown-rs canceled.

Thanks for looking into this @AlonMiz. We'll try to add some bundle size regression checks in the Analog repo to alert us about this. The Angular CLI has an option to use Rolldown for chunk optimization, so its worth them checking the impact there also.

cc: @alan-agius4

Thanks @brandonroberts for ping. Let me loop in @clydin.