fix(pack): preserve cyclic reexports

[fireairforce]

What

• update the next.js submodule to include fix(turbopack): preserve cyclic reexports next.js#178
• add a minimal Pack snapshot for a class imported through the same barrel that re-exports it
• refresh the existing complex circular re-export snapshot for the lazy namespace fallback

Why

A cyclic barrel can expose a re-export getter before its generated namespace binding has been initialized. The linked Turbopack fix keeps normal reads unchanged, but lets circuit-breaker getters fall back to the module namespace that already exists in the runtime cache.

Related

• [Bug] 集成 LogicFlow 时报错 umijs/umi#13410

Dependency

• Depends on fix(turbopack): preserve cyclic reexports next.js#178

Checks

• cargo test -p pack-tests --test snapshot reexport_cycle -- --nocapture
• cargo clippy -p pack-tests --all-targets -- -D warnings --no-deps
• cargo fmt --all -- --check
• pre-push formatting and Biome checks
• git diff --check

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260812_030936
Generated: 2026-08-12 03:09:36
Trace File: trace_antd.json (0.4GB, 1.13M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	7,552.3 ms	Baseline
Total Thread Work (de-duped)	22,863.5 ms	Non-overlapping busy time
Effective Parallelism	3.0x	thread_work / wall_time
Working Threads	10	Threads with actual spans
Thread Utilization	30.3%	⚠️ Suboptimal
Total Spans	1,128,342	All B/E + X events
Meaningful Spans (>= 10us)	351,597	(31.2% of total)
Tracing Noise (< 10us)	776,745	(68.8% of total)

---

Build Phase Timeline

Shows when each build phase is active and how much CPU it consumes.
Self-Time is the time spent exclusively in that phase (excluding children).

Phase	Spans	Inclusive (ms)	Self-Time (ms)	Wall Range (ms)
Resolve	92,339	3,048.7	2,389.9	4,270.9
Parse	10,027	1,215.6	1,151.8	6,957.9
Analyze	225,081	14,826.5	10,587.9	6,857.0
Chunk	8,315	2,838.8	799.5	2,348.7
Codegen	10,053	1,460.9	1,375.7	2,039.0
Emit	32	47.9	24.0	11.1
Other	5,750	6,152.1	3,701.4	7,552.3

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	320,218	18,258.0	79.9%	13,223.3	57.8%
P1: I/O & Heavy Tasks	2,899	128.0	0.6%	104.1	0.5%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	26,888	5,524.3	24.2%	3,335.9	14.6%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	1,592	5,680.3	24.8%	3,366.8	14.7%

---

Top 20 Tasks by Self-Time

Self-time is the exclusive duration: time spent in the task itself, not in sub-tasks.
This is the most accurate indicator of where CPU cycles are actually spent.

Self (ms)	Inclusive (ms)	Count	Avg Self (us)	P95 Self (ms)	Max Self (ms)	% Work	Task Name	Top Caller
5,827.9	8,243.1	143,975	40.5	0.1	12.6	25.5%	module	write all entrypoints to disk (1%)
2,393.3	2,431.2	25,415	94.2	0.2	288.3	10.5%	analyze ecmascript module	module (66%)
2,178.9	2,267.0	27	80701.8	369.0	545.8	9.5%	save snapshot	persist (4%)
1,512.5	3,273.0	47,106	32.1	0.0	8.5	6.6%	process module	module (21%)
1,491.2	1,605.9	51,271	29.1	0.0	6.5	6.5%	internal resolving	resolving (29%)
1,079.5	1,143.3	7,859	137.4	0.5	33.6	4.7%	parse ecmascript	process module (25%)
890.9	1,434.9	40,369	22.1	0.0	8.6	3.9%	resolving	module (31%)
775.0	775.0	7,666	101.1	0.4	8.3	3.4%	precompute code generation	generate merged code (51%)
710.1	710.1	5,770	123.1	0.5	101.1	3.1%	compute async module info	compute merged modules (0%)
681.6	1,996.6	1,302	523.5	1.2	238.7	3.0%	generate merged code	chunking (70%)
665.4	2,703.7	6,590	101.0	0.1	42.6	2.9%	chunking	compute async chunks (0%)
396.5	396.5	329	1205.2	1.1	240.3	1.7%	generate source map	code generation (83%)
384.2	732.5	173	2220.8	4.4	203.1	1.7%	emit code	generate merged code (32%)
294.5	424.2	3,765	78.2	0.0	134.0	1.3%	write all entrypoints to disk	None (0%)
204.2	289.4	2,058	99.2	0.2	42.6	0.9%	code generation	chunking (11%)
130.7	131.7	1,676	78.0	0.1	11.2	0.6%	compute async chunks	compute async chunks (0%)
98.8	98.8	15	6584.2	28.9	77.4	0.4%	blocking	save snapshot (60%)
81.2	81.2	661	122.8	0.0	19.0	0.4%	compute binding usage info	write all entrypoints to disk (1%)
72.3	72.3	2,166	33.4	0.0	3.1	0.3%	read file	parse ecmascript (91%)
51.1	51.1	1,989	25.7	0.0	6.8	0.2%	collect mergeable modules	compute merged modules (6%)

---

Critical Path Analysis

The longest sequential dependency chains that determine wall-clock time.
Focus on reducing the depth of these chains to improve parallelism.

Rank	Self-Time (ms)	Depth	Path
1	553.8	3	persist → save snapshot → blocking
2	441.8	3	chunking → generate merged code → emit code
3	288.4	2	process module → analyze ecmascript module
4	287.7	4	chunking → generate merged code → emit code → generate source map
5	152.9	2	save snapshot → blocking

---

Batching Candidates

High-volume tasks dominated by a single parent. If the parent can batch them,
it drastically reduces scheduler overhead.

Task Name	Count	Top Caller (Attribution)	Avg Self	P95 Self	Total Self
No obvious batching candidates found	-	-	-	-	-

---

Duration Distribution

Range	Count	Percentage
<10us	776,745	68.8%
10us-100us	331,611	29.4%
100us-1ms	15,602	1.4%
1ms-10ms	4,261	0.4%
10ms-100ms	102	0.0%
>100ms	21	0.0%

---

Action Items

1. [P0] Focus on tasks with the highest Self-Time — these are where CPU cycles are actually spent.
2. [P0] Use Batching Candidates to identify callers that should use try_join or reduce #[turbo_tasks::function] granularity.
3. [P1] Check Build Phase Timeline for phases with disproportionate wall range vs. self-time (= serialization).
4. [P1] Inspect P95 Self (ms) for heavy monolith tasks. Focus on long-tail outliers, not averages.
5. [P1] Review Critical Paths — reducing the longest chain depth directly improves wall-clock time.
6. [P2] If Thread Utilization < 60%, investigate scheduling gaps (lock contention or deep dependency chains).

Report generated by Utoopack Performance Analysis Agent