[fireairforce]

Summary

closes: #2480

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 handling of external scripts within the Turbopack runtime. It introduces a specialized and cached method for loading external scripts dynamically, improving reliability and performance for dependencies sourced from CDNs or other external locations. The changes ensure that script externals are properly integrated and managed, addressing a previous issue and enhancing the overall stability of the packing process.

Highlights

• New loadScript Function: Introduced a dedicated loadScript function within the UMD runtime to handle external script loading via <script> tags, including caching to prevent redundant loads.
• Runtime Type Definitions: Updated the runtime type definitions to include the new LoadScript type and integrate it into the TurbopackBaseContext interface.
• Snapshot Test Updates: Added new snapshot tests for asynchronous script externals and updated existing tests to utilize the new loadScript mechanism, ensuring correct behavior and error handling for external script dependencies.
• Submodule Update: Updated the next.js submodule to its latest commit.

Changelog

• crates/pack-core/js/src/umd/runtime-base.ts
  • Added loadScript function to browserContextPrototype.S for external script loading.
  • Implemented caching for loadScript using loadedScripts Map to prevent duplicate script requests.
• crates/pack-core/js/src/umd/runtime-types.d.ts
  • Added LoadScript type definition.
  • Included S: LoadScript in the TurbopackBaseContext interface.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/config.json
  • Added new test configuration for async script externals.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/input/index.ts
  • Added new input file for async script externals test.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/_externals____2fc6bb03.js
  • Added new output file demonstrating async external script loading.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/_externals____2fc6bb03.js.map
  • Added source map for the new external script output.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/_root-of-the-server___fa01a871.js
  • Added new output file for the root server in async external script test.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/_root-of-the-server___fa01a871.js.map
  • Added source map for the new root server output.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/main.js
  • Added new main output file for the async script externals test.
• crates/pack-tests/tests/snapshot/externals/async-script-externals/output/main.js.map
  • Added source map for the new main output.
• crates/pack-tests/tests/snapshot/externals/basic/output/_root-of-the-server___3b647096.js
  • Updated script external loading logic to use __turbopack_context__.S instead of L.
  • Improved error handling for failed script loads.
• crates/pack-tests/tests/snapshot/externals/basic/output/_root-of-the-server___3b647096.js.map
  • Updated source map offset due to changes in generated JavaScript.
• crates/pack-tests/tests/snapshot/externals/script/output/_externals____2fc6bb03.js
  • Updated script external loading logic to use __turbopack_context__.S instead of L.
  • Improved error handling for failed script loads.
• crates/pack-tests/tests/snapshot/public_path/basic/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/public_path/runtime/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/runtime/app_build_runtime/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/runtime/app_dev_runtime/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/runtime/export_entry_exports/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/runtime/library_build_runtime/output/main.js
  • Included the new loadScript function and its assignment to browserContextPrototype.S.
• crates/pack-tests/tests/snapshot/runtime/library_build_runtime/output/main.js.map
  • Updated source map sections due to changes in generated JavaScript.
• next.js
  • Updated the next.js submodule commit.

Activity

• The pull request description indicates it closes issue [Utoopack] script externals 加载不生效 #2480.
• No human comments or reviews have been recorded yet.

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

This pull request introduces a new loadScript function for handling script externals, which is a great improvement. The implementation correctly uses a cache to avoid re-loading scripts. The PR also includes new tests and refactors existing ones to use this new function, which is excellent.

I have one suggestion to improve the robustness of the loadScript function by allowing retries on transient network failures. Other than that, the changes look solid.

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260211_190310
Generated: 2026-02-11 19:03:10
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	8,349.0 ms	Baseline
Total Thread Work (de-duped)	26,390.8 ms	Non-overlapping busy time
Effective Parallelism	3.2x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	63.2%	🆗 Average
Total Spans	1,588,525	All B/E + X events
Meaningful Spans (>= 10us)	524,472	(33.0% of total)
Tracing Noise (< 10us)	1,064,053	(67.0% 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,965	3,603.3	13.7%
P3: Asset Pipeline	29,357	3,912.6	14.8%
P4: Bridge/Interop	0	0.0	0.0%
Other	456,150	22,143.2	83.9%

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)	26,390.8 ms
Avg Work per Thread	5,278.2 ms
Effective Parallelism	3.16x
Thread Utilization	63.2%

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
8,584.2	188,574	45.5	15.5	32.5%	module
4,068.8	72,016	56.5	189.6	15.4%	process module
3,503.4	36,077	97.1	189.5	13.3%	analyze ecmascript module
2,782.3	24,918	111.7	63.4	10.5%	code generation
1,896.6	14,309	132.5	152.1	7.2%	chunking
1,891.5	59,427	31.8	9.5	7.2%	resolving
1,847.4	63,507	29.1	8.6	7.0%	internal resolving
1,386.6	31,637	43.8	8.2	5.3%	precompute code generation
1,247.6	12,902	96.7	146.4	4.7%	compute async module info
1,038.2	8,081	128.5	40.1	3.9%	parse ecmascript
589.7	4,925	119.7	61.2	2.2%	compute async chunks
298.6	1,936	154.2	17.6	1.1%	generate source map
88.7	2,165	40.9	6.3	0.3%	read file
83.2	1,850	45.0	17.8	0.3%	collect mergeable modules
73.7	635	116.0	26.0	0.3%	compute binding usage info
73.5	100	735.3	22.9	0.3%	make production chunks
42.7	7	6100.4	22.9	0.2%	compute merged modules
35.5	14	2533.1	11.0	0.1%	apply effects
34.4	14	2454.1	10.8	0.1%	write file
19.3	565	34.1	0.9	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.2% suggests critical path serialization or lock contention.
• 1,064,053 spans < 10us (67.0%) 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,603.3 ms	✅ Healthy
Large Tasks (> 100ms)	6	Critical

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

Focus: Global state and transformation pipeline.

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

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,064,053	67.0%
10us - 100us	498,574	31.4%
100us - 1ms	21,711	1.4%
1ms - 10ms	4,101	0.3%
10ms - 100ms	80	0.0%
> 100ms	6	0.0%

---

Diagnostic Signal Summary

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