[fireairforce]

Summary

优化 async externals chunk 的 filename 名称。

ref pr: utooland/next.js#113

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!

This pull request refines the naming convention for asynchronous external script chunks within the pack system, aiming to simplify and standardize the generated filenames. The changes include updates to internal module references and the introduction of new snapshot tests to validate the correct bundling and referencing of external scripts, thereby enhancing the reliability of external module integration.

Highlights

• Filename Simplification: Simplified the filename generation logic for asynchronous external script chunks, leading to more consistent and potentially shorter filenames.
• Module ID Updates: Updated internal module IDs and references within generated JavaScript files to align with the new filename generation scheme.
• New Snapshot Tests: Added a comprehensive set of new snapshot tests specifically for external script handling, ensuring the correctness and stability of the updated filename generation and external module loading.

Changelog

• crates/pack-tests/tests/snapshot/externals/basic/output/_root-of-the-server___a4c79e8f.js
  • Renamed the file to reflect the new filename generation.
  • Updated module IDs from 462 to 17 and 747 to 596.
• crates/pack-tests/tests/snapshot/externals/basic/output/_root-of-the-server___a4c79e8f.js.map
  • Renamed the source map file to match the new JavaScript filename.
• crates/pack-tests/tests/snapshot/externals/basic/output/main.js
  • Updated the otherChunks reference to point to the new external script chunk filename.
• crates/pack-tests/tests/snapshot/externals/script/config.json
  • Added a new configuration for an external lodash script.
• crates/pack-tests/tests/snapshot/externals/script/input/index.ts
  • Added a new TypeScript entry file that imports lodash asynchronously.
• crates/pack-tests/tests/snapshot/externals/script/output/_externals____2fc6bb03.js
  • Added a new generated JavaScript file for the external lodash script.
• crates/pack-tests/tests/snapshot/externals/script/output/_externals____2fc6bb03.js.map
  • Added the source map for the new external lodash script file.
• crates/pack-tests/tests/snapshot/externals/script/output/_root-of-the-server___7ced73a1.js
  • Added a new generated JavaScript file for the main entry point, referencing the external lodash script.
• crates/pack-tests/tests/snapshot/externals/script/output/_root-of-the-server___7ced73a1.js.map
  • Added the source map for the main entry point JavaScript file.
• crates/pack-tests/tests/snapshot/externals/script/output/main.js
  • Added a new main.js file for the external script test, referencing the main entry point chunk.
• crates/pack-tests/tests/snapshot/externals/script/output/main.js.map
  • Added the source map for the new main.js file.
• next.js
  • Updated the next.js subproject commit hash.

Activity

• No specific pull request activity (comments, reviews, etc.) was provided in the context.

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 旨在优化异步外部脚本块（async externals script chunk）的文件名。您通过更新快照测试反映了模块 ID 的变化，并为 script 类型的 externals 添加了新的快照测试，这很好地覆盖了相关场景。

我在新生成的快照文件中发现了一个可以改进的地方：在浏览器等非 Node.js 环境中，global 对象可能未定义。建议使用 globalThis 来确保代码在不同 JavaScript 环境中的兼容性。

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260211_033525
Generated: 2026-02-11 03:35:25
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,857.6 ms	Baseline
Total Thread Work (de-duped)	24,934.5 ms	Non-overlapping busy time
Effective Parallelism	3.2x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	63.5%	🆗 Average
Total Spans	1,589,315	All B/E + X events
Meaningful Spans (>= 10us)	503,180	(31.7% of total)
Tracing Noise (< 10us)	1,086,135	(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	37,961	3,407.1	13.7%
P3: Asset Pipeline	28,506	3,506.7	14.1%
P4: Bridge/Interop	0	0.0	0.0%
Other	436,713	20,864.7	83.7%

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,934.5 ms
Avg Work per Thread	4,986.9 ms
Effective Parallelism	3.17x
Thread Utilization	63.5%

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

---

Top 20 Tasks by Total Duration

Total (ms)	Count	Avg (us)	Max (ms)	% Work	Task Name
7,913.8	179,325	44.1	19.1	31.7%	module
3,958.8	68,864	57.5	147.4	15.9%	process module
3,338.7	35,092	95.1	147.3	13.4%	analyze ecmascript module
2,733.9	24,519	111.5	66.0	11.0%	code generation
1,744.7	57,286	30.5	9.5	7.0%	resolving
1,667.6	61,034	27.3	8.0	6.7%	internal resolving
1,646.9	13,842	119.0	139.3	6.6%	chunking
1,321.7	29,613	44.6	7.7	5.3%	precompute code generation
1,220.7	12,909	94.6	121.9	4.9%	compute async module info
994.1	8,041	123.6	50.4	4.0%	parse ecmascript
486.6	4,580	106.3	48.8	2.0%	compute async chunks
301.3	1,936	155.6	18.0	1.2%	generate source map
71.4	1,857	38.5	15.3	0.3%	collect mergeable modules
67.1	621	108.1	20.4	0.3%	compute binding usage info
62.8	101	622.1	17.0	0.3%	make production chunks
58.4	2,166	27.0	0.3	0.2%	read file
32.9	14	2347.7	10.3	0.1%	apply effects
32.7	5	6548.4	16.5	0.1%	compute merged modules
31.3	13	2411.4	9.5	0.1%	write file
29.6	573	51.6	2.8	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 63.5% suggests critical path serialization or lock contention.
• 1,086,135 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,407.1 ms	✅ Healthy
Large Tasks (> 100ms)	5	Minimal

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

Focus: Global state and transformation pipeline.

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

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,086,135	68.3%
10us - 100us	478,769	30.1%
100us - 1ms	20,554	1.3%
1ms - 10ms	3,769	0.2%
10ms - 100ms	83	0.0%
> 100ms	5	0.0%

---

Diagnostic Signal Summary

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

---

Action Items (P0-P4)

1. [P0] Profile lock contention to address 36% 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