chore: add foreign jsx transform test case

[fireairforce]

Summary

添加一组 foreign jsx transform 的测试 case

Test Plan

[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!

此拉取请求主要通过重构 source_maps 配置逻辑来优化代码，并引入了一个新的快照测试用例，以确保 foreign jsx transform 功能的正确性。这有助于提高代码的可维护性，并增强对特定 JSX 转换场景的测试覆盖。

Highlights

• 源码映射配置重构: 将 source_maps 的判断逻辑提取到一个局部变量中，并在 EcmascriptOptionsContext 和 CssOptionsContext 中复用，以减少重复代码。
• 新增 JSX 转换测试用例: 添加了一组新的快照测试用例，用于验证 foreign jsx transform 的行为，包括其配置、输入、预期的错误输出以及生成的 JavaScript 和 Source Map 文件。

Changelog

• crates/pack-core/src/client/context.rs
  • 重构了 source_maps 的获取逻辑，将其提取为局部变量。
  • 在 EcmascriptOptionsContext 和 CssOptionsContext 中复用了重构后的 source_maps 变量。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/config.json
  • 新增了测试配置，定义了入口文件 input/index.js。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/input/index.js
  • 新增了测试输入文件，导入了 foreign-jsx-transform 模块。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/issues/Ecmascript-file-had-an-error-df4108.txt
  • 新增了预期的错误输出文件，展示了当 pragma 与 runtime 自动模式冲突时的错误信息。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/node_modules/foreign-jsx-transform/index.js
  • 新增了模拟的 foreign-jsx-transform 模块，包含 /** @jsx jsx */ pragma。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/node_modules/foreign-jsx-transform/package.json
  • 新增了 foreign-jsx-transform 模块的 package.json 文件。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project__basic_foreign_jsx_transform_9ec7bd5f.js
  • 新增了测试用例的预期输出 JavaScript 文件。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project__basic_foreign_jsx_transform_9ec7bd5f.js.map
  • 新增了测试用例的预期输出 Source Map 文件。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/main.js
  • 新增了主入口文件的预期输出 JavaScript 文件。
• crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/main.js.map
  • 新增了主入口文件的预期输出 Source Map 文件。

Activity

• 目前没有检测到任何评论或审查活动。

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 的主要内容是为 foreign JSX transform 添加了一组快照测试用例，同时包含了一个小的代码重构。
crates/pack-core/src/client/context.rs 中的重构通过预先计算 source_maps 的值，避免了代码重复和潜在的重复异步调用，提高了代码的可读性和性能。
新增的测试用例验证了在 node_modules 中的文件（foreign code）使用 JSX pragma 时，如果 JSX 运行时设置为 "automatic"，会正确地抛出错误。这是一个有价值的测试场景。
代码整体质量很高，但在新添加的测试文件中发现了一些可以改进的地方，详见具体的审查意见。

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260211_064808
Generated: 2026-02-11 06:48:08
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,914.9 ms	Baseline
Total Thread Work (de-duped)	24,709.7 ms	Non-overlapping busy time
Effective Parallelism	3.1x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	62.4%	🆗 Average
Total Spans	1,588,717	All B/E + X events
Meaningful Spans (>= 10us)	503,038	(31.7% of total)
Tracing Noise (< 10us)	1,085,679	(68.3% 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	38,029	3,479.2	14.1%
P3: Asset Pipeline	28,943	3,228.4	13.1%
P4: Bridge/Interop	0	0.0	0.0%
Other	436,066	20,841.0	84.3%

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)	24,709.7 ms
Avg Work per Thread	4,941.9 ms
Effective Parallelism	3.12x
Thread Utilization	62.4%

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
7,946.3	180,503	44.0	12.7	32.2%	module
3,932.1	68,235	57.6	199.2	15.9%	process module
3,409.2	35,168	96.9	199.1	13.8%	analyze ecmascript module
2,688.6	24,297	110.7	59.0	10.9%	code generation
1,694.3	56,896	29.8	10.1	6.9%	resolving
1,662.8	60,871	27.3	5.8	6.7%	internal resolving
1,369.7	13,900	98.5	50.2	5.5%	chunking
1,366.9	28,862	47.4	11.2	5.5%	precompute code generation
1,263.2	13,220	95.6	125.1	5.1%	compute async module info
996.5	8,033	124.1	80.5	4.0%	parse ecmascript
505.8	4,963	101.9	47.9	2.0%	compute async chunks
291.6	1,936	150.6	16.4	1.2%	generate source map
73.5	614	119.8	25.0	0.3%	compute binding usage info
60.9	2,166	28.1	3.0	0.2%	read file
52.3	1,871	28.0	7.9	0.2%	collect mergeable modules
50.1	105	476.8	13.5	0.2%	make production chunks
34.6	14	2472.5	9.7	0.1%	apply effects
33.9	13	2608.6	9.7	0.1%	write file
27.0	588	45.9	2.5	0.1%	async reference
24.8	8	3095.0	12.7	0.1%	compute merged modules

---

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.4% suggests critical path serialization or lock contention.
• 1,085,679 spans < 10us (68.3%) 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,479.2 ms	✅ Healthy
Large Tasks (> 100ms)	3	Minimal

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

Focus: Global state and transformation pipeline.

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

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,085,679	68.3%
10us - 100us	478,564	30.1%
100us - 1ms	20,563	1.3%
1ms - 10ms	3,827	0.2%
10ms - 100ms	81	0.0%
> 100ms	3	0.0%

---

Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	⚠️ Significant	68.3% of spans < 10us
Thread Utilization (P0)	🆗 Average	62.4% utilization
Heavy Monoliths (P1)	✅ Minimal	3 tasks > 100ms
Asset Pipeline (P3)	Review	3,228.4 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