Inside of Rolldown, there're multiple passes touch chunks. Like removing unnecessary ones or do some optimizations. They're all built on top of a bare raw Chunk struct.
Bad: Every pass tries to define its own lanague to do similar stuffs.
Owners:
- feature
avoidRedundantChunkLoads
predicted_static_import_targets tries to predict something
- feature
mergeCommonChunks
would_create_circular_dependency can_merge_without_changing_entry_signature try to predict something
- feature
onDemandWrapping
predicted_static_import_edges tries to predict somethinglowered_static_import_edges alters the chunk graph
At least 3 passes transform/modify the chunk graph, using their own language.
Bad: Every pass interacts with business logic directly rather than abstracts it into domain properties
The point is separating a feature's business logic from the nature it represents.
preserveEntrySignatures: 'strict' means the entry should keep its export signature. Its nature for chunk optimization is a domain property: this chunk's export surface is frozen, no pass may add exports to it.
Marking the feature on the chunk is not enough. We already do that (chunk.preserve_entry_signature), and the pass is still messy: it still has to know what each feature implies.
!chunk.is_async_entry()
&& !matches!(chunk.preserve_entry_signature, Some(PreserveEntrySignatures::Strict))
These two checks are the same domain property spelled as two feature checks: "this chunk's export surface is frozen". A third feature that also freezes the export surface would add a third &&.
Chunks should carry a domain property like export_surface: Frozen | Extendable. Lowering translates every feature onto that one property — preserveEntrySignatures, async entry, whatever comes next.
The optimizer reads the property and never knows the feature exists. The test of a good domain property: multiple features converge onto one.
The worst case today is is_strict_execution_order_enabled(), which forks a whole pass into two graphs inline.
Inside of Rolldown, there're multiple passes touch chunks. Like removing unnecessary ones or do some optimizations. They're all built on top of a bare raw
Chunkstruct.Bad: Every pass tries to define its own lanague to do similar stuffs.
Owners:
avoidRedundantChunkLoadspredicted_static_import_targetstries to predict somethingmergeCommonChunkswould_create_circular_dependencycan_merge_without_changing_entry_signaturetry to predict somethingonDemandWrappingpredicted_static_import_edgestries to predict somethinglowered_static_import_edgesalters the chunk graphAt least 3 passes transform/modify the chunk graph, using their own language.
Bad: Every pass interacts with business logic directly rather than abstracts it into domain properties
The point is separating a feature's business logic from the nature it represents.
preserveEntrySignatures: 'strict'means the entry should keep its export signature. Its nature for chunk optimization is a domain property: this chunk's export surface is frozen, no pass may add exports to it.Marking the feature on the chunk is not enough. We already do that (
chunk.preserve_entry_signature), and the pass is still messy: it still has to know what each feature implies.These two checks are the same domain property spelled as two feature checks: "this chunk's export surface is frozen". A third feature that also freezes the export surface would add a third
&&.Chunks should carry a domain property like
export_surface: Frozen | Extendable. Lowering translates every feature onto that one property —preserveEntrySignatures, async entry, whatever comes next.The optimizer reads the property and never knows the feature exists. The test of a good domain property: multiple features converge onto one.
The worst case today is
is_strict_execution_order_enabled(), which forks a whole pass into two graphs inline.