fix(pack): restore package fallback for declaration-only paths

[fireairforce]

Summary

A runtime package import mapped only to .d.ts files in compilerOptions.paths can become undefined after declaration filtering, causing (void 0) is not a function. Update the Turbopack submodule to keep a fallback-capable mapping so the original package request can resolve through exports or main.

The change preserves default tsconfig handling, exact/wildcard and inherited mapping precedence, valid candidate order, explicitly empty path arrays, and browser: false behavior. Add executable browser-library and server regressions plus a missing-runtime-package diagnostic regression. Snapshots are generated against the current production chunk naming scheme.

Depends on utooland/next.js#191. The submodule commit is published on that PR branch; merge the submodule fix first and retain or update this pointer to its merged commit.

Public reproduction: https://github.com/fireairforce/turbopack-dts-paths-repro

Test Plan

• Confirmed both new regressions fail before the fix, including (void 0) is not a function when executing the bundle.
• cargo test -p pack-tests typescript: 13 passed after rebasing onto the latest next branch.
• cargo clippy --all-targets -- -D warnings --no-deps: passed.
• cargo clippy -p turbopack-resolve --all-targets -- -D warnings --no-deps: passed.
• Rust formatting, tombi format --check, biome ci, and typos: passed.

Full cargo test -p pack-tests was also attempted. On the current base, the first failure is a generated chunk snapshot mismatch in basic/alias; subsequent snapshot failures cascade from the poisoned shared test lock. During the earlier baseline comparison at 4051a7eb0, this same fixture also failed with the resolver fix removed because its expected Less/CSS nav export was missing. The full suite is therefore not claimed as passing. No unrelated snapshots were updated.

Cargo validation used CARGO_PROFILE_DEV_DEBUG=0 CARGO_PROFILE_TEST_DEBUG=0.

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260909_101436
Generated: 2026-09-09 10:14:36
Trace File: trace_antd.json (0.3GB, 0.82M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	6,673.4 ms	Baseline
Total Thread Work (de-duped)	20,220.1 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	819,577	All B/E + X events
Meaningful Spans (>= 10us)	223,065	(27.2% of total)
Tracing Noise (< 10us)	596,512	(72.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	50,223	7,316.4	2,047.2	3,354.1
Parse	8,165	1,367.2	1,023.0	6,135.5
Analyze	143,038	41,229.1	9,651.2	6,046.1
Chunk	5,833	5,915.4	938.0	2,416.1
Codegen	12,405	2,500.5	1,517.6	2,063.2
Emit	35	39.6	19.8	8.9
Other	3,366	6,207.8	3,427.2	6,673.4

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	193,743	49,044.9	242.6%	11,898.5	58.8%
P1: I/O & Heavy Tasks	2,909	107.0	0.5%	87.2	0.4%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	25,121	9,850.6	48.7%	3,526.9	17.4%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	1,292	5,573.7	27.6%	3,111.3	15.4%

---

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,077.3	26,187.9	99,036	51.3	0.1	20.2	25.1%	module	module (62%)
2,127.8	2,273.1	2,486	855.9	2.8	218.3	10.5%	analyze ecmascript module	module (70%)
2,022.7	2,073.5	18	112372.2	340.9	495.8	10.0%	save snapshot	persist (6%)
1,479.5	11,560.9	31,281	47.3	0.1	7.4	7.3%	process module	process module (81%)
1,338.0	3,557.8	27,461	48.7	0.1	6.0	6.6%	internal resolving	internal resolving (77%)
966.5	1,310.7	5,998	161.1	0.6	32.3	4.8%	parse ecmascript	parse ecmascript (65%)
873.9	969.6	10,091	86.6	0.4	6.4	4.3%	precompute code generation	generate merged code (39%)
810.9	5,698.2	4,088	198.4	0.3	101.4	4.0%	chunking	chunking (45%)
801.9	915.4	7,465	107.4	0.4	128.6	4.0%	compute async module info	compute async module info (56%)
698.3	3,747.8	22,055	31.7	0.0	4.7	3.5%	resolving	module (55%)
644.0	2,129.6	1,011	637.0	1.5	196.8	3.2%	generate merged code	chunking (44%)
415.0	415.0	329	1261.4	1.0	243.1	2.1%	generate source map	code generation (83%)
366.9	778.8	130	2822.4	5.0	200.8	1.8%	emit code	emit code (53%)
294.2	552.1	1,690	174.1	0.1	156.8	1.5%	write all entrypoints to disk	write all entrypoints to disk (17%)
228.6	1,115.9	1,985	115.2	0.3	45.1	1.1%	code generation	code generation (84%)
122.6	212.2	1,652	74.2	0.1	9.7	0.6%	compute async chunks	compute async chunks (53%)
104.9	124.0	885	118.5	0.0	36.9	0.5%	compute binding usage info	compute binding usage info (40%)
56.5	56.5	2,165	26.1	0.0	2.1	0.3%	read file	parse ecmascript (91%)
53.1	53.1	5	10620.7	33.8	39.5	0.3%	blocking	save snapshot (60%)
48.1	83.9	1,867	25.8	0.0	18.0	0.2%	collect mergeable modules	collect mergeable modules (100%)

---

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	507.0	3	persist → save snapshot → blocking
2	401.3	6	chunking → generate merged code → emit code → emit code → emit code → read file
3	280.7	4	chunking → generate merged code → emit code → generate source map
4	218.5	3	process module → process module → analyze ecmascript module
5	207.7	5	chunking → chunking → generate merged code → emit code → generate source map

---

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
process module	31,281	process module (81%)	47.3 us	0.07 ms	1,479.5 ms
internal resolving	27,461	internal resolving (77%)	48.7 us	0.09 ms	1,338.0 ms

---

Duration Distribution

Range	Count	Percentage
<10us	596,512	72.8%
10us-100us	146,491	17.9%
100us-1ms	64,967	7.9%
1ms-10ms	11,370	1.4%
10ms-100ms	206	0.0%
>100ms	31	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