refactor(pack): check worker_threads support, remove useless configs

[xusd320]

1. check where worker_threads can be used for webpack loaders driver, also close [Utoopack] unexpected crash on nodejs@22 #2657
2. remove useless configs

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the project's configuration management by eliminating experimental settings and streamlining config handling across both Rust and TypeScript components. It also introduces a more robust and dynamic approach to selecting runtime plugin strategies, ensuring compatibility and optimal performance based on the Node.js environment. These changes aim to simplify the codebase, remove deprecated features, and enhance the overall maintainability and adaptability of the system.

Highlights

• Configuration Refactoring: Removed the ExperimentalConfig struct and associated fields/methods from Rust (crates/pack-core/src/config.rs), including react_compiler and cache_handler handling. Similarly, the ExperimentalConfig interface and related fields were removed from TypeScript config definitions (packages/pack-shared/src/config.ts).
• Runtime Plugin Strategy Improvements: Added a new utility function useWorkerThreads that leverages semver to dynamically select the plugin runtime strategy (worker threads or child processes) based on the current Node.js version. This new strategy is now integrated into the build and hot reloader logic.
• Dependency Updates: Added semver as a new dependency and updated peer dependencies to include styled-jsx in packages/pack/package.json.
• Code Cleanup: Cleaned up unused code and comments in import_map.rs and improved consistency in how config options are accessed throughout the codebase. The packages/pack/src/commands/dev-legacy.ts file was entirely removed.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively refactors the configuration by removing experimental settings and introducing a dynamic runtime plugin strategy based on Node.js version. The changes are well-aligned with the description, including dependency updates and cleanup of legacy code. The new useWorkerThreads utility provides a clear mechanism for runtime selection. Overall, the changes improve the codebase's clarity and adaptability.

[yuzheng14]

workerThread 不可用的情况下，用户仍然配置了 workerThread，是不是弹一个 warning 提示用户比较合适？

[xusd320]

用户不用关心这个，能跑就行

[xusd320]

改了一下策略，默认按照用户配置的 pluginRuntimeStrategy，绝大部分用户应该都不需要配置这个。

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260319_031516
Generated: 2026-03-19 03:15:16
Trace File: trace_antd.json (0.6GB, 1.74M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	14,696.4 ms	Baseline
Total Thread Work (de-duped)	50,341.1 ms	Non-overlapping busy time
Effective Parallelism	3.4x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	68.5%	🆗 Average
Total Spans	1,742,857	All B/E + X events
Meaningful Spans (>= 10us)	640,688	(36.8% of total)
Tracing Noise (< 10us)	1,102,169	(63.2% 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	143,145	8,231.2	6,632.1	10,461.2
Parse	12,392	2,717.7	2,358.7	14,506.9
Analyze	372,757	36,213.6	27,923.9	13,963.0
Chunk	29,587	2,966.6	2,753.6	11,869.6
Codegen	69,786	5,307.1	3,968.9	11,965.2
Emit	75	78.3	39.0	11,118.2
Other	12,946	2,444.5	2,117.8	14,696.4

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	525,120	46,090.5	91.6%	35,902.4	71.3%
P1: I/O & Heavy Tasks	3,316	204.7	0.4%	165.5	0.3%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	110,574	10,994.4	21.8%	9,084.4	18.0%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	1,678	669.3	1.3%	641.8	1.3%

---

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
18,201.0	20,525.0	232,116	78.4	0.1	59.6	36.2%	module	write all entrypoints to disk (1%)
4,814.1	6,455.1	40,001	120.3	0.2	191.6	9.6%	analyze ecmascript module	process module (73%)
3,458.7	3,693.0	67,244	51.4	0.0	26.0	6.9%	internal resolving	resolving (29%)
3,343.8	7,633.7	79,241	42.2	0.1	58.6	6.6%	process module	module (16%)
3,158.5	4,523.3	75,187	42.0	0.0	26.9	6.3%	resolving	module (33%)
1,983.5	3,321.6	27,426	72.3	0.2	70.1	3.9%	code generation	chunking (7%)
1,949.3	2,053.3	9,015	216.2	0.6	74.6	3.9%	parse ecmascript	analyze ecmascript module (27%)
1,898.9	2,080.9	16,726	113.5	0.2	101.6	3.8%	chunking	write all entrypoints to disk (0%)
1,658.3	1,658.3	40,279	41.2	0.1	18.5	3.3%	precompute code generation	code generation (28%)
1,413.4	1,709.0	10,266	137.7	0.0	405.1	2.8%	write all entrypoints to disk	None (0%)
1,364.7	1,364.7	18,008	75.8	0.3	155.4	2.7%	compute async module info	chunking (0%)
815.4	816.0	12,694	64.2	0.1	74.9	1.6%	compute async chunks	compute async chunks (0%)
588.5	606.8	1,445	407.3	1.0	33.7	1.2%	webpack loader	parse css (12%)
327.1	327.1	2,081	157.2	0.4	17.8	0.6%	generate source map	code generation (96%)
297.8	552.8	850	350.4	1.1	20.6	0.6%	parse css	module (6%)
114.6	114.6	1,336	85.8	0.0	29.8	0.2%	compute binding usage info	write all entrypoints to disk (0%)
111.3	111.3	2,508	44.4	0.1	9.4	0.2%	read file	parse ecmascript (85%)
62.6	66.3	1,002	62.5	0.1	6.6	0.1%	async reference	write all entrypoints to disk (1%)
62.4	62.4	2,018	30.9	0.0	11.7	0.1%	collect mergeable modules	compute merged modules (0%)
39.4	69.7	167	235.6	0.4	26.1	0.1%	make production chunks	chunking (2%)

---

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	191.7	2	process module → analyze ecmascript module
2	94.6	2	process module → analyze ecmascript module
3	87.9	2	code generation → generate source map
4	87.6	2	process module → analyze ecmascript module
5	74.7	2	analyze ecmascript module → parse ecmascript

---

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
analyze ecmascript module	40,001	process module (73%)	120.3 us	0.20 ms	4,814.1 ms

---

Duration Distribution

Range	Count	Percentage
<10us	1,102,169	63.2%
10us-100us	605,380	34.7%
100us-1ms	27,267	1.6%
1ms-10ms	7,349	0.4%
10ms-100ms	685	0.0%
>100ms	7	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