The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
rollup	Ready	Preview, Comment	Jun 8, 2026 9:44am

Thank you for your contribution! ❤️

You can try out this pull request locally by installing Rollup via

npm install rollup/rollup#fix/manual-chunk-optimize

Notice: Ensure you have installed the latest nightly Rust toolchain. If you haven't installed it yet, please see https://www.rust-lang.org/tools/install to learn how to download Rustup and install Rust.

or load it into the REPL:
https://rollup-7akn5mqe4-rollup-js.vercel.app/repl/?pr=6374

Performance report

• BUILD: 7128ms, 856 MB
  • initialize: 0ms, 24 MB (+8%)
  • generate module graph: 2742ms, 641 MB
    • generate ast: 1410ms (-30ms, -2.1%), 629 MB
  • sort and bind modules: 408ms, 707 MB
  • mark included statements: 3977ms, 856 MB
    • treeshaking pass 1: 2345ms, 844 MB
    • treeshaking pass 2: 464ms, 850 MB
    • treeshaking pass 3: 398ms, 854 MB
    • treeshaking pass 4: 384ms, 822 MB
    • treeshaking pass 5: 379ms, 856 MB
• GENERATE: 695ms, 924 MB
  • initialize render: 0ms, 856 MB
  • generate chunks: 38ms, 864 MB (+3%)
    • optimize chunks: 0ms, 870 MB
  • render chunks: 644ms, 911 MB
  • transform chunks: 21ms, 924 MB
  • generate bundle: 0ms, 924 MB

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.78%. Comparing base (126e141) to head (d2e69c8).

@@           Coverage Diff           @@
##           master    #6374   +/-   ##
=======================================
  Coverage   98.78%   98.78%           
=======================================
  Files         274      274           
  Lines       10789    10806   +17     
  Branches     2882     2882           
=======================================
+ Hits        10658    10675   +17     
  Misses         89       89           
  Partials       42       42           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Thanks a lot for taking the time to look into this so deeply, especially with your limited Rollup time!

Yeah, I agree with you. When working on this PR, I also thought about a similar approach: refactoring the chunk atom creation logic and treating modules in manual chunks more like dependent entries. But that felt like a larger change and would take more time, so I went with the current symptom fix for now.

and I wonder if this problem could not re-appear on a higher level if you have multiple entries with the exact same dependencies that are also shared by a manual chunk.

For this specific case, I do not think the issue should reappear, but I may be missing something 😅

I can try to move this towards the long-term solution, since I currently have quite a bit of spare time 😄

Of course, if you have already started looking into it, I’m happy to leave it to you to avoid duplicating the work.

I want to give it a shot tomorrow morning, I will let you know how to go on then

I pushed a solution similar to what I had in mind. So basically what it does is that for the purpose of generating chunks, it partially treats manual chunks like entry points:

If both an entry and a manual chunk import a module, then it will always end up in a third chunk.

What is different from entry points is that static dependencies that only the manual chunk has will not be merged into the manual chunk automatically. This is currently only relevant for explicit manual chunks, though, where this behavior is not desired anyway.

I am not 100% sure if we want to have this in the way I implemented it, but it is quite efficient and should resolve many circular dependency scenarios.

Wow, that was really fast. Looks good to me — nice approach!

I think I am happy with the implementation now. I added an improvement to actually treat all modules in the manual chunk as one module with regard to finding static dependencies. That avoids creating too many other chunks, see the added test where this change reduces the chunk count by one.

For Rollup 5, I think I would actually extend this idea to rework how manual chunks are created. Instead of just collecting static dependencies, I would like to treat manual chunk definitions really just like entry points and assign the alias to the chunk that contains all the modules that defined the chunk. This will lead to slightly smaller manual chunks if the array form is used, but I think will much more closely follow expectations.
I would also like to un-deprecate the onlyExplicitManualChunks flag and apply it both to the array and the function form, albeit with a default of false for array and true for the function form. If it is true, we stick to the logic of this PR and just add those modules to the chunk. If it is false, we treat them more-or-less as entry points for the chunking logic.

I added an improvement to actually treat all modules in the manual chunk as one module with regard to finding static dependencies. That avoids creating too many other chunks, see the added test where this change reduces the chunk count by one.

I think this logic needs one more condition: it should only apply when all modules in the manual chunk have the same dependent entries.

For example, in the test, if we change the imports of manual1 and manual2 from static imports to dynamic imports, then the expected behavior should be that their static dependencies are not bundled into a single shared chunk.

For Rollup 5, I think I would actually extend this idea to rework how manual chunks are created. Instead of just collecting static dependencies, I would like to treat manual chunk definitions really just like entry points and assign the alias to the chunk that contains all the modules that defined the chunk. This will lead to slightly smaller manual chunks if the array form is used, but I think will much more closely follow expectations.

Nice, looking forward to it!

I would also like to un-deprecate the onlyExplicitManualChunks flag and apply it both to the array and the function form, albeit with a default of false for array and true for the function form. If it is true, we stick to the logic of this PR and just add those modules to the chunk. If it is false, we treat them more-or-less as entry points for the chunking logic.

Sounds good to me.

I added an improvement to actually treat all modules in the manual chunk as one module with regard to finding static dependencies. That avoids creating too many other chunks, see the added test where this change reduces the chunk count by one.

I think this logic needs one more condition: it should only apply when all modules in the manual chunk have the same dependent entries.

For example, in the test, if we change the imports of manual1 and manual2 from static imports to dynamic imports, then the expected behavior should be that their static dependencies are not bundled into a single shared chunk.

Hi @lukastaegert, what do you think? Does that make sense?

I thought about this but I am pretty sure that we do not need this condition. Even in my test, there is no guarantee that both entry points are loaded. So you have this graph with entry points E1 and E2

graph LR

E1 --> M1
M1 --> D1
E2 --> M2
M2 --> D2

subgraph manual
M1
M2
end

As I understand you, you would put D1 and D2 into separate chunks. However after bundling, you get

graph LR

E1 --> manual
manual --> D1
E2 --> manual
manual --> D2

where manual has D1 and D2 as static dependencies. So whenever manual is loaded, both D1 and D2 are loaded, and it would not help to put them into separate chunks. That is why it makes sense to treat all members of manual as the same module because the manual chunk is "merging" all their dependencies artificially. And it should not make a difference if E1 and E2 are static or dynamic entry points.

Oh, sorry about that. I should have been looking at test/chunking-form/samples/manual-chunk-with-unrelated-files/_config.js, but I was looking at test/chunking-form/samples/shared-static-dependency-between-manual-chunks/_config.js instead. Sorry for the confusion.

This PR has been released as part of rollup@4.62.0. You can test it via npm install rollup.