chore: upgrade next.js

[fireairforce]

Summary

同步上游 next.js 改动，把丢失的 pr: https://github.com/utooland/next.js/pull/78/changes 添加回来

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!

此拉取请求旨在将 next.js 子项目同步到上游的最新更改，并重新引入一个之前可能丢失的关于 worker 创建和处理的特定 PR。核心改动包括更新依赖、优化 Rust 代码中 chunk 的解析流程，以及改进 JavaScript 运行时中 worker 的实例化方法，使其更加灵活和健壮。这些更新通过相应的快照测试反映出来，确保了功能的正确性。

Highlights

• Next.js 子项目升级: 将 next.js 子项目更新至新的提交版本 a4c05f3e04d1a88e5c3e7fe2308e9bb52a34eb4f，以同步上游改动。
• 核心打包逻辑改进: 重构了 chunking_context.rs 中处理 Vc 类型的方式，引入 ResolvedVc 并对结果进行解引用，以更安全和高效地处理 chunk 解析和类型转换。
• Worker 创建机制更新: 将 getWorkerURL 函数重命名为 createWorker，并修改其签名以接受 WorkerConstructor 和 workerOptions。新的实现能够区分 SharedWorker 并正确处理 worker 选项，例如移除 type: "module"。
• 快照测试更新: 更新了多个快照测试输出，以反映 define/complex 中编译时值注入的改变以及 public_path 和 runtime 测试中 worker 创建逻辑的调整。

Changelog

• Cargo.lock
  • 移除了 thiserror 1.0.69 依赖项。
• crates/pack-core/src/library/chunking_context.rs
  • 更新了 Vc::try_resolve_downcast_type 和 Vc::try_resolve_sidecast 的调用，改为使用 ResolvedVc 的方法并对结果进行解引用。
  • 添加了 chunk.to_resolved().await? 调用以确保 chunk 已解析。
• crates/pack-tests/tests/snapshot/define/complex/output/input_index_ts_291b4280.js
  • 更新了 console.log 输出，为 RoutePathEnum 的值添加了 ("TURBOPACK compile-time value", ...) 包装。
• crates/pack-tests/tests/snapshot/define/complex/output/input_index_ts_291b4280.js.map
  • 更新了源映射文件以匹配新的 JavaScript 输出。
• crates/pack-tests/tests/snapshot/public_path/basic/output/main.js
  • 将 getWorkerURL 函数重命名为 createWorker。
  • 修改了 createWorker 函数的参数，增加了 WorkerConstructor 和 workerOptions。
  • 添加了逻辑以识别 SharedWorker 并从 workerOptions 中移除 type: "module"。
• crates/pack-tests/tests/snapshot/public_path/runtime/output/main.js
  • 将 getWorkerURL 函数重命名为 createWorker。
  • 修改了 createWorker 函数的参数，增加了 WorkerConstructor 和 workerOptions。
  • 添加了逻辑以识别 SharedWorker 并从 workerOptions 中移除 type: "module"。
• crates/pack-tests/tests/snapshot/runtime/app_build_runtime/output/main.js
  • 将 getWorkerURL 函数重命名为 createWorker。
  • 修改了 createWorker 函数的参数，增加了 WorkerConstructor 和 workerOptions。
  • 添加了逻辑以识别 SharedWorker 并从 workerOptions 中移除 type: "module"。
• crates/pack-tests/tests/snapshot/runtime/app_dev_runtime/output/main.js
  • 将 getWorkerURL 函数重命名为 createWorker。
  • 修改了 createWorker 函数的参数，增加了 WorkerConstructor 和 workerOptions。
  • 添加了逻辑以识别 SharedWorker 并从 workerOptions 中移除 type: "module"。
• crates/pack-tests/tests/snapshot/runtime/export_entry_exports/output/main.js
  • 将 getWorkerURL 函数重命名为 createWorker。
  • 修改了 createWorker 函数的参数，增加了 WorkerConstructor 和 workerOptions。
  • 添加了逻辑以识别 SharedWorker 并从 workerOptions 中移除 type: "module"。
• next.js
  • 更新了 next.js 子项目的提交哈希。

Activity

• 此拉取请求旨在同步上游 next.js 的改动，并重新添加一个之前丢失的 PR。
• 为了验证这些更改，快照测试已更新。

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 旨在将上游 next.js 的改动同步回来。主要改动涉及在 crates/pack-core/src/library/chunking_context.rs 中对 Vc 的处理方式，以及更新了一些 JavaScript 快照测试。

我对代码进行了一些审查，发现 chunking_context.rs 中的改动引入了类型不匹配的 bug，这些都被标记为 critical 级别。此外，一些 JavaScript 文件的改动似乎是为了更好地处理 worker 的创建和 URL。

总体来说，同步上游是好的，但需要确保这些改动在我们的代码库中是正确的，特别是解决这些类型问题。

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260210_075149
Generated: 2026-02-10 07:51:49
Trace File: trace_antd.json (1.4GB, 7.32M events)
Test Project: examples/with-antd

---

📊 Executive Summary

This report analyzes the performance of Utoopack/Turbopack, covering the full spectrum of the Performance Analysis Protocol (P0-P4).

Key Findings

Metric	Value	Assessment
Total Wall Time	8,779.6 ms	Baseline
Total Thread Work	78,918.9 ms	~9.0x parallelism
Thread Utilization	179.8%	✅ Good
turbo_tasks::function Invocations	3,539,905	Total count
Meaningful Tasks (≥ 10µs)	1,280,921	(36.2% of total)
Tracing Noise (< 10µs)	2,258,984	(63.8% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	863,097	46,785.2	59.3%
P1: I/O & Heavy Tasks	35,222	3,067.3	3.9%
P3: Asset Pipeline	28,589	4,047.4	5.1%
P4: Bridge/Interop	0	0.0	0.0%
Other	354,013	17,603.1	22.3%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	5
Total Thread Work	78,918.9 ms
Avg Work per Thread	15,783.8 ms
Theoretical Parallelism	8.99x
Thread Utilization	179.8%

Assessment: With 5 threads available, achieving 9.0x parallelism indicates reasonable throughput.

---

📈 Top 20 Tasks (Global)

These are the most significant tasks by total duration:

Total (ms)	Count	Avg (µs)	% Work	Task Name
39,228.4	716,985	54.7	49.7%	turbo_tasks::function
8,146.0	121,104	67.3	10.3%	task execution completed
5,390.0	67,619	79.7	6.8%	turbo_tasks::resolve_call
2,683.0	32,366	82.9	3.4%	analyze ecmascript module
1,851.2	59,068	31.3	2.3%	resolving
1,726.4	26,201	65.9	2.2%	module
1,562.7	24,264	64.4	2.0%	effects processing
1,512.5	39,831	38.0	1.9%	precompute code generation
1,500.4	12,910	116.2	1.9%	process parse result
945.6	6,099	155.0	1.2%	parse ecmascript
907.9	32,212	28.2	1.2%	internal resolving
717.8	24,966	28.7	0.9%	process module
711.7	26,269	27.1	0.9%	resolve_relative_request
561.9	1,910	294.2	0.7%	analyze variable values
427.3	14,327	29.8	0.5%	resolve_module_request
394.9	13,839	28.5	0.5%	handle_after_resolve_plugins
387.6	1,937	200.1	0.5%	generate source map
341.8	1,938	176.4	0.4%	swc_parse
341.0	16,235	21.0	0.4%	resolved
332.7	8,901	37.4	0.4%	code generation

---

🔍 Deep Dive by Tier

🔴 Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

Metric	Value	Status
Total Scheduling Time	46,785.2 ms	⚠️ High
Resolution Hotspots	9 tasks	🔍 Check Top Tasks

Potential P0 Issues:

• Low thread utilization (179.8%) suggests critical path serialization or lock contention.
• 2,258,984 tasks < 10µs (63.8%) 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,067.3 ms	✅ Healthy
Large Tasks (> 100ms)	16	🚨 Critical

Potential P1 Issues:

• 16 tasks exceed 100ms. These "Heavy Monoliths" are prime candidates for splitting.

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

Focus: Global state and transformation pipeline.

Metric	Value	Status
Asset Processing (P3)	4,047.4 ms	5.1% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

Problem: 179.8% thread utilization.
Action:

1. Profile lock contention if utilization < 60%.
2. Convert sequential await chains to try_join.

⚠️ High Priority: (P1) Optimization

Problem: 16 heavy tasks detected.
Action:

1. Identify module-level bottlenecks (e.g., barrel files).
2. Optimize I/O batching for metadata.

⚠️ Medium Priority: (P3) Pipeline Efficiency

Action:

1. Review transformation logic for frequently changed assets.
2. Minimize cross-language serialization (P4) if overhead exceeds 10%.

---

📐 Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	⚠️ Significant	63.8% of tasks < 10µs
Thread Utilization (P0)	✅ Good	179.8% utilization
Heavy Monoliths (P1)	⚠️ Detected	16 tasks > 100ms
Asset Pipeline (P3)	🔍 Review	4,047.4 ms total
Bridge/Interop (P4)	✅ Low	0.0 ms total

---

🎯 Action Items (Comprehensive P0-P4)

1. [P0] Investigate task scheduling gaps for incremental gains
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-10
Following: Utoopack Performance Analysis Agent Protocol