refactor(web): remove separate sync fs polyfill and use unified entry

[xusd320]

Refactors the file system polyfills for the web target. Removes the separate sync implementation and points to the main index in fsPolyfill.

[gemini-code-assist]

Summary of Changes

Hello @xusd320, 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 refactors the web filesystem polyfills by consolidating the synchronous filesystem implementation into a unified entry point. It removes a custom block_on function in the Rust WASM module, opting for the runtime's native blocking mechanism, and updates the TypeScript definitions and import paths to align with this streamlined architecture.

Highlights

• Rust block_on Removal: The custom block_on function in crates/utoo-wasm/src/fs.rs has been removed, streamlining asynchronous operations by directly utilizing the tokio_runtime's block_on method for various filesystem operations.
• Unified FS Polyfill Entry: The sync.ts file within packages/utoo-web/src/webpackLoaders/polyfills/fsPolyfill/ has been renamed to index.ts, establishing a single, unified entry point for the filesystem polyfill.
• TypeScript Definition Updates: The InitOutput interface in packages/utoo-web/src/utoo/index.d.ts has been updated, reflecting changes in the exposed WASM functions and their ordering, along with regenerated wasm_bindgen closure signatures.
• Import Path Adjustment: The import statement for the fs polyfill in packages/utoo-web/src/webpackLoaders/polyfills/nodePolyFills.ts has been adjusted to point to the new unified index.ts entry.

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 is a solid refactoring that simplifies the codebase. In the Rust code, it correctly replaces a custom block_on implementation with the more robust and standard tokio::runtime::block_on. On the web side, it unifies the synchronous and asynchronous filesystem polyfills into a single module, which improves code organization. I've found one correctness issue in the rmSync polyfill implementation which could lead to incorrect behavior, and I've provided a suggestion to fix it.

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260202_075302
Generated: 2026-02-02 07:53:02
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	10,344.1 ms	Baseline
Total Thread Work	89,688.8 ms	~8.7x parallelism
Thread Utilization	48.2%	⚠️ Suboptimal
turbo_tasks::function Invocations	3,882,050	Total count
Meaningful Tasks (≥ 10µs)	1,524,261	(39.3% of total)
Tracing Noise (< 10µs)	2,357,789	(60.7% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	1,044,914	54,236.6	60.5%
P1: I/O & Heavy Tasks	37,070	3,899.7	4.3%
P3: Asset Pipeline	27,698	4,357.9	4.9%
P4: Bridge/Interop	0	0.0	0.0%
Other	414,579	19,809.4	22.1%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	18
Total Thread Work	89,688.8 ms
Avg Work per Thread	4,982.7 ms
Theoretical Parallelism	8.67x
Thread Utilization	48.2%

Assessment: With 18 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
45,329.0	869,475	52.1	50.5%	turbo_tasks::function
8,634.2	124,700	69.2	9.6%	task execution completed
6,321.4	81,545	77.5	7.0%	turbo_tasks::resolve_call
2,958.4	32,131	92.1	3.3%	analyze ecmascript module
2,195.2	66,507	33.0	2.4%	precompute code generation
2,047.4	68,046	30.1	2.3%	resolving
1,818.5	35,392	51.4	2.0%	module
1,704.9	20,469	83.3	1.9%	effects processing
1,550.3	11,536	134.4	1.7%	process parse result
1,117.0	6,416	174.1	1.2%	parse ecmascript
1,040.4	31,848	32.7	1.2%	process module
1,016.2	35,858	28.3	1.1%	internal resolving
835.6	28,538	29.3	0.9%	resolve_relative_request
624.6	1,911	326.8	0.7%	analyze variable values
583.5	1	583546.0	0.7%	make root node for strongly consistent read
469.9	19,650	23.9	0.5%	handle_after_resolve_plugins
443.8	15,472	28.7	0.5%	resolve_module_request
443.8	17,475	25.4	0.5%	resolved
440.2	1,941	226.8	0.5%	swc_parse
395.0	10,817	36.5	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	54,236.6 ms	⚠️ High
Resolution Hotspots	9 tasks	🔍 Check Top Tasks

Potential P0 Issues:

• Low thread utilization (48.2%) suggests critical path serialization or lock contention.
• 2,357,789 tasks < 10µs (60.7%) 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,899.7 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,357.9 ms	4.9% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

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

---

🎯 Action Items (Comprehensive P0-P4)

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