Class declarations in circular chunks are not converted, which will cause TDZ errors similar to const/let. The top_level_var block above (lines 1544-1548) handles class declarations by transforming them, but this circular deps handler only converts variable declarations.

If a module uses export class MyClass {} in a circular chunk, it will still throw TDZ errors. The fix should include:

if self.ctx.chunk_graph.chunks_with_circular_deps.contains(&self.ctx.chunk_idx) {
  if let Statement::VariableDeclaration(var_decl) = &mut top_stmt {
    var_decl.kind = ast::VariableDeclarationKind::Var;
    for decl in &mut var_decl.declarations {
      decl.kind = VariableDeclarationKind::Var;
    }
  }
  // Add class handling:
  if let Statement::ClassDeclaration(class_decl) = &mut top_stmt {
    if let Some(mut decl) = self.get_transformed_class_decl(class_decl) {
      top_stmt = Statement::from(decl.take_in(self.alloc));
    }
  }
}

Spotted by Graphite Agent



Is this helpful? React 👍 or 👎 to let us know.

detect_circular_chunk_deps only detects mutual imports (A↔B). A longer cycle (A→B→C→A) won’t mark any chunk here, but it’s still a circular chunk dependency and can still trigger TDZ issues. Consider detecting all cycles (e.g., SCC via Tarjan/Kosaraju, marking SCCs with size>1, or a DFS back-edge check) so every chunk participating in any cycle is covered.

This loop allocates a Vec of keys (keys().copied().collect::<Vec<_>>()) just to iterate. If you keep the current approach, you can iterate keys directly (or restructure the algorithm) to avoid per-chunk allocations during generation.

The top_level_var block and the circular-deps block duplicate the same “convert VariableDeclaration to var + transform ClassDeclaration” logic. Consider extracting a small helper (or combining the conditions) to avoid divergence if this transformation needs to change later.

detect_circular_chunk_deps() currently only detects direct mutual imports (A↔B). Any longer chunk cycle (e.g. A→B→C→A) will not be marked in chunks_with_circular_deps, so the const/let→var safety net in module_finalizers won’t run for those chunks and TDZ ReferenceErrors can still happen. Consider switching this to a proper cycle/SCC detection over the chunk import graph (and clear chunks_with_circular_deps at the start of the pass to avoid stale data if the method is ever called more than once).

The docstring says longer cycles "would require SCC detection" and are "uncommon in practice," but the PR description states "Transitive chains (A→B→C→A) and cycles emerging after chunk optimization still rely on the safety net." This discrepancy should be resolved — the doc comment should explicitly note that transitive cycles are handled by the const/let→var safety net layer rather than implying they are simply out of scope.

I prefer to warn the user and let them decide whether to enable topLevelVar. (Because there is not only one way to solve circular references)

This is also how rollup handle circularChunks
https://github.com/rollup/rollup/blob/ae846957f109690a866cc3e4c073613c338d3476/src/Bundle.ts#L234-L273

The PR description describes a "Layer 2: Safety net" with three components: chunks_with_circular_deps + detect_circular_chunk_deps() in chunk_graph.rs, const/let→var conversion in module_finalizers/mod.rs, a call to detect_circular_chunk_deps() in generate_stage/mod.rs, and a cross_chunk_tdz_esm_safety_net test case. None of these are present in the actual diff or the current codebase. The table in the PR description lists these as changes in the PR, but they are absent. If the safety net is intentionally omitted (i.e., only Layer 1 is included), the PR description should be updated to reflect this. If these changes were supposed to be included, they are missing from the PR.

The cycle detection check at line 180 uses self.index_splitting_info[dep].bits == self.index_splitting_info[rdep].bits to determine if dep and rdep are in the same chunk. However, this comparison is based on the pre-manual-splitting bit state — it does not account for the fact that dep might also be assigned to a different manual splitting group and thus moved to a different chunk. This can produce false positives: a split may be prevented even when splitting would not actually create a circular dependency (because dep would itself end up in a separate manual chunk, not in the same chunk as rdep). This is a known limitation (mentioned in the PR description for transitive cycles), but this specific over-approximation applies to direct cycles too. The practical impact is that some valid splits may be unnecessarily blocked when multiple manual groups overlap in their target modules.

The prevent_circular_chunk_deps function is called before extract_runtime_chunk, which means the runtime module could still be present in group.modules during cycle analysis. For the runtime module specifically, if it is included in a group (unlikely in practice, but possible if a regex matches it), cycle prevention would run on it. The runtime module typically has WrapKind::None but represents a special module. Since extract_runtime_chunk removes it from groups right after, this ordering issue is benign in practice but could produce misleading PreventedManualSplit entries for the runtime module that are never emitted (because after removal by extract_runtime_chunk, the runtime module would be in module_to_assigned, suppressing the warning). This is a minor ordering concern but not a critical correctness bug.