feat(pack): support config jsx runtime by tsconfig

[fireairforce]

Summary

支持通过 tsconfig.json 里面的 compilerOptions.jsx 来设置 utoopack 处理 jsx 的方式。

turbopack 需要支持 next.js 框架行为，该配置并没有打开，且所有的场景 jsx runtime 默认都为 automatic，参考: https://github.com/vercel/next.js/blob/canary/crates/next-core/src/transform_options.rs#L170-L173

一些场景下 utoopack 需要按照 classic 的方式来编译 node_modules 中的依赖产物:

如图为某项目的代码产物，这类需要按照 classic 的方式来进行 jsx 编译。

utoopack 需要一个配置来设置 jsx 的 runtime 类型，目前先暂定从 tsconfig.json 的 compilerOptions.jsx 里面读取来转换(跟 tsx 的行为保持一致)，后续需要单独的配置再考虑开出去。

Test Plan

在快照测试: #2588 的基础上做了一些调整

[gemini-code-assist]

Summary of Changes

Hello @fireairforce, 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!

此拉取请求旨在增强 utoopack 对 JSX 转换的配置能力，允许开发者通过 tsconfig.json 文件中的 compilerOptions.jsx 选项来指定 JSX 运行时。这解决了在某些情况下，特别是处理 node_modules 中的旧版依赖时，需要使用 'classic' JSX 运行时而非默认 'automatic' 运行时的问题，从而提供了更大的灵活性和兼容性。

Highlights

• 支持通过 tsconfig.json 配置 JSX 运行时: 现在可以通过 tsconfig.json 中的 compilerOptions.jsx 字段来设置 utoopack 处理 JSX 的方式。
• 映射 TypeScript JSX 选项到运行时: 将 tsconfig.json 中 compilerOptions.jsx 的值 'react' 映射为 'classic' 运行时，将 'react-jsx' 或 'react-jsxdev' 映射为 'automatic' 运行时。
• 解决 node_modules 依赖的 JSX 编译问题: 此更改允许 utoopack 按照 'classic' 方式编译 node_modules 中的依赖产物，以适应特定场景的需求。

Changelog

• crates/pack-core/src/client/context.rs
  • 重构了 jsx_runtime_options 变量的命名为 jsx_transform_options，以更准确地反映其用途。
  • 移除了 ModuleOptionsContext 初始化时默认的 enable_typescript_transform 和 enable_jsx 配置。
  • 为 foreign_codes_options_context 和 internal_context 显式地设置了 enable_jsx 和 enable_typescript_transform 选项，确保了不同模块上下文的正确配置。
• crates/pack-core/src/transform_options.rs
  • 删除了关于 Next.js 强制使用 automatic 运行时且不允许通过 tsconfig 覆盖的注释。
  • 在 get_jsx_transform_options 函数中添加了逻辑，根据 tsconfig.json 中 compilerOptions.jsx 的值来确定 JSX 运行时，将 'react' 映射到 'classic'，将 'react-jsx' 或 'react-jsxdev' 映射到 'automatic'。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/issues/Ecmascript-file-had-an-error-df4108.txt
  • 移除了一个旧的快照测试文件，该文件可能与之前的 JSX 运行时错误相关。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/tsconfig.json
  • 新增了一个 tsconfig.json 测试文件，其中 compilerOptions.jsx 被设置为 'react'，用于验证新的 JSX 运行时配置功能。

Activity

• 作者 fireairforce 提交了此拉取请求，旨在支持通过 tsconfig.json 配置 JSX 运行时。
• 拉取请求包含一个详细的摘要，解释了更改的背景和目的。
• 添加了一组快照测试，以验证新的 JSX 运行时配置逻辑的正确性。

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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

这个 PR 旨在通过 tsconfig.json 中的 compilerOptions.jsx 来支持配置 JSX 运行时。这对于需要 classic 运行时的 node_modules 依赖项非常有用。代码更改看起来是正确的，并且很好地将新的 JSX 转换选项应用到了不同的代码上下文（用户代码、外部依赖、内部资源）。测试也已相应更新，以验证新功能。我有一个关于代码可读性和惯用法的建议。

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260211_101517
Generated: 2026-02-11 10:15:17
Trace File: trace_antd.json (0.5GB, 3.18M events)
Test Project: examples/with-antd

---

Executive Summary

Key Findings

Metric	Value	Assessment
Total Wall Time	7,236.0 ms	Baseline
Total Thread Work (de-duped)	22,623.5 ms	Non-overlapping busy time
Effective Parallelism	3.1x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	62.5%	🆗 Average
Total Spans	1,589,284	All B/E + X events
Meaningful Spans (>= 10us)	419,316	(26.4% of total)
Tracing Noise (< 10us)	1,169,968	(73.6% of total)

Note on Thread Work: Thread work is computed by merging overlapping intervals
per thread, eliminating double-counting from nested spans. This gives the true
wall-clock busy time across all threads.

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Thread Work
P0: Runtime/Resolution	0	0.0	0.0%
P1: I/O & Heavy Tasks	34,864	3,282.8	14.5%
P3: Asset Pipeline	26,220	3,425.9	15.1%
P4: Bridge/Interop	0	0.0	0.0%
Other	358,232	18,140.1	80.2%

Note: Percentages may sum to >100% because task durations include nesting
while thread work is de-duplicated. This is intentional for hotspot attribution.

---

Parallelization Analysis

Thread Utilization

Metric	Value
Working Threads	5
Total Thread Work (de-duped)	22,623.5 ms
Avg Work per Thread	4,524.7 ms
Effective Parallelism	3.13x
Thread Utilization	62.5%

Assessment: With 5 working threads, achieving 3.1x parallelism indicates significant loss of potential parallelism.

---

Top 20 Tasks by Total Duration

Total (ms)	Count	Avg (us)	Max (ms)	% Work	Task Name
6,590.4	143,412	46.0	12.0	29.1%	module
3,570.4	58,829	60.7	195.8	15.8%	process module
3,202.5	31,992	100.1	195.7	14.2%	analyze ecmascript module
2,463.5	22,665	108.7	62.4	10.9%	code generation
1,524.8	52,366	29.1	12.0	6.7%	internal resolving
1,493.2	47,355	31.5	11.8	6.6%	resolving
1,375.3	12,045	114.2	52.2	6.1%	chunking
1,123.6	9,476	118.6	134.6	5.0%	compute async module info
1,085.2	21,267	51.0	12.5	4.8%	precompute code generation
987.2	7,695	128.3	36.3	4.4%	parse ecmascript
699.1	4,448	157.2	101.0	3.1%	compute async chunks
284.1	1,936	146.7	17.1	1.3%	generate source map
81.5	1,849	44.1	19.4	0.4%	collect mergeable modules
69.9	2,165	32.3	5.1	0.3%	read file
64.2	90	713.8	21.4	0.3%	make production chunks
60.7	513	118.3	17.6	0.3%	compute binding usage info
40.6	7	5796.4	21.4	0.2%	compute merged modules
28.7	14	2053.3	9.4	0.1%	apply effects
28.0	13	2154.9	9.4	0.1%	write file
15.2	409	37.1	2.0	0.1%	async reference

---

Deep Dive by Tier

Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

Metric	Value	Status
Total Scheduling Time	0.0 ms	✅ Normal
Resolution Hotspots	0 distinct task types	Check Top Tasks

Potential P0 Issues:

• Thread utilization at 62.5% suggests critical path serialization or lock contention.
• 1,169,968 spans < 10us (73.6%) contribute to scheduler pressure.

Tier 2: Physical & Resource Barriers (P1)

Focus: Hardware utilization, I/O, and heavy monoliths.

Metric	Value	Status
I/O Work (Estimated)	3,282.8 ms	✅ Healthy
Large Tasks (> 100ms)	4	Minimal

Tier 3: Architecture & Asset Pipeline (P2-P3)

Focus: Global state and transformation pipeline.

Metric	Value	Status
Asset Processing (P3)	3,425.9 ms	15.1% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,169,968	73.6%
10us - 100us	396,739	25.0%
100us - 1ms	19,109	1.2%
1ms - 10ms	3,385	0.2%
10ms - 100ms	79	0.0%
> 100ms	4	0.0%

---

Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	⚠️ Significant	73.6% of spans < 10us
Thread Utilization (P0)	🆗 Average	62.5% utilization
Heavy Monoliths (P1)	✅ Minimal	4 tasks > 100ms
Asset Pipeline (P3)	Review	3,425.9 ms total
Bridge/Interop (P4)	Low	0.0 ms total

---

Action Items (P0-P4)

1. [P0] Profile lock contention to address 37% lost parallelism
2. [P1] Breakdown heavy monolith tasks (>100ms) to improve granularity
3. [P1] Review I/O patterns for potential batching opportunities
4. [P3] Optimize asset transformation pipeline hot-spots
5. [P4] Reduce "chatty" bridge operations if interop overhead is significant

---

Report generated by Utoopack Performance Analysis Agent on 2026-02-11
Following: Utoopack Performance Analysis Agent Protocol

[xusd320]

这不对吧？foreign codes 应该用自己包内的 tsconfig ?

[fireairforce]

这个之前都是不会读的，走默认的

[fireairforce]