feat(pack): compitable with windows

[fireairforce]

Summary

closes: #2479

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 significantly enhances the pack feature's compatibility with Windows operating systems by addressing fundamental differences in path handling. It introduces a set of robust utility functions for path normalization, absolute path detection, and separator stripping, which are then integrated into the core logic. This ensures that the application can correctly interpret and manipulate file paths regardless of the underlying operating system, resolving potential issues related to path conventions.

Highlights

• Windows Path Utilities: New utility functions is_absolute_path, to_unix_path, and strip_leading_separator have been introduced in pack-core/src/util.rs to correctly handle Windows-specific path formats and ensure cross-platform compatibility.
• Refactored Path Handling: Existing path manipulation logic within pack-api/src/project.rs and pack-core/src/util.rs has been updated to utilize these new utility functions, standardizing how paths are processed across different operating systems.
• Dependency Update: The regex crate has been added as a new dependency to pack-core to support the implementation of the is_absolute_path function, which uses regular expressions to detect various Windows absolute path patterns.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 changes to make the pack crate compatible with Windows by handling different path formats. The changes are well-structured, introducing utility functions for path manipulation like is_absolute_path, to_unix_path, and strip_leading_separator. This centralizes the logic and improves code clarity and maintainability. The use of regex for Windows path detection and Cow for efficient string manipulation are good choices. Overall, this is a solid improvement for cross-platform compatibility. I have one minor suggestion to make the code more idiomatic.

[xusd320]

workflow 里 windows ci/cd 开一下

[fireairforce]

workflow 里 windows ci/cd 开一下

ok，我先把这个 pr 的基本能力做完先

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260128_034555
Generated: 2026-01-28 03:45:55
Trace File: trace_antd.json (1.5GB, 8.00M events)
Test Project: Unknown Project

---

📊 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	9,969.9 ms	Baseline
Total Thread Work	87,074.4 ms	~8.7x parallelism
Thread Utilization	67.2%	🆗 Average
turbo_tasks::function Invocations	3,883,134	Total count
Meaningful Tasks (≥ 10µs)	1,506,821	(38.8% of total)
Tracing Noise (< 10µs)	2,376,313	(61.2% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	1,033,117	52,650.8	60.5%
P1: I/O & Heavy Tasks	36,738	3,604.2	4.1%
P3: Asset Pipeline	27,888	4,237.8	4.9%
P4: Bridge/Interop	0	0.0	0.0%
Other	409,078	19,105.3	21.9%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	13
Total Thread Work	87,074.4 ms
Avg Work per Thread	6,698.0 ms
Theoretical Parallelism	8.73x
Thread Utilization	67.2%

Assessment: With 13 threads available, achieving 8.7x parallelism indicates significant loss of potential parallelism.

---

📈 Top 20 Tasks (Global)

These are the most significant tasks by total duration:

Total (ms)	Count	Avg (µs)	% Work	Task Name
43,748.1	860,871	50.8	50.2%	turbo_tasks::function
8,130.8	121,975	66.7	9.3%	task execution completed
6,302.7	80,601	78.2	7.2%	turbo_tasks::resolve_call
2,978.6	31,819	93.6	3.4%	analyze ecmascript module
2,127.3	66,675	31.9	2.4%	precompute code generation
2,015.9	67,415	29.9	2.3%	resolving
1,750.6	20,320	86.2	2.0%	effects processing
1,705.3	35,317	48.3	2.0%	module
1,511.6	11,725	128.9	1.7%	process parse result
1,072.9	6,381	168.1	1.2%	parse ecmascript
1,032.8	35,361	29.2	1.2%	internal resolving
965.4	30,615	31.5	1.1%	process module
835.5	28,233	29.6	1.0%	resolve_relative_request
613.7	1,914	320.7	0.7%	analyze variable values
468.2	15,306	30.6	0.5%	resolve_module_request
430.7	10,845	39.7	0.5%	code generation
430.1	1,939	221.8	0.5%	swc_parse
419.2	17,410	24.1	0.5%	resolved
406.2	18,380	22.1	0.5%	handle_after_resolve_plugins
366.7	4,224	86.8	0.4%	read file

---

🔍 Deep Dive by Tier

🔴 Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

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

Potential P0 Issues:

• Low thread utilization (67.2%) suggests critical path serialization or lock contention.
• 2,376,313 tasks < 10µs (61.2%) 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,604.2 ms	✅ Healthy
Large Tasks (> 100ms)	22	🚨 Critical

Potential P1 Issues:

• 22 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,237.8 ms	4.9% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

Problem: 67.2% thread utilization.
Action:

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

⚠️ High Priority: (P1) Optimization

Problem: 22 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	61.2% of tasks < 10µs
Thread Utilization (P0)	✅ Good	67.2% utilization
Heavy Monoliths (P1)	⚠️ Detected	22 tasks > 100ms
Asset Pipeline (P3)	🔍 Review	4,237.8 ms total
Bridge/Interop (P4)	✅ Low	0.0 ms total

---

🎯 Action Items (Comprehensive P0-P4)

1. [P0] Profile lock contention to address 32% 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-01-28
Following: Utoopack Performance Analysis Agent Protocol