chore/bump deps and improve fs

[xusd320]

• feat(utoo-web): improve fs error translation, support cjs extension, and standardize resolution
• chore: bump tokio-fs-ext to 0.7.7 and update next.js submodule
• fix(wasm): export error constants from rust to ensure consistency with js polyfill

[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 focuses on enhancing the robustness and compatibility of the file system (FS) operations within the utoo-web project, particularly concerning its WebAssembly (WASM) integration. It introduces more granular error translation from Rust WASM to JavaScript, ensuring that FS-related errors are consistently mapped to standard Node.js error codes. Additionally, it improves the module resolution mechanism to properly handle .cjs files and updates key dependencies, contributing to a more stable and feature-rich environment.

Highlights

• Improved File System Error Handling: Enhanced error translation in utoo-web to provide more specific Node.js-like error codes (e.g., ENOENT, EISDIR) from Rust WASM errors, ensuring consistency with JS polyfills.
• CJS Module Resolution Support: Added support for .cjs file extensions and standardized module resolution logic within utoo-web's webpack loaders.
• Dependency Updates: Bumped the tokio-fs-ext Rust crate to version 0.7.5 and updated the next.js git submodule.
• WASM Error Constant Export: Exported specific error constants from the Rust WASM module to JavaScript, facilitating more robust error mapping on the JS side.

Changelog

• Cargo.lock
  • Updated tokio-fs-ext from 0.7.3 to 0.7.5.
• Cargo.toml
  • Updated tokio-fs-ext dependency to 0.7.5.
• crates/utoo-wasm/src/errors.rs
  • Introduced a define_error_consts! macro to declare Rust string constants and export them as wasm_bindgen functions to JavaScript.
  • Defined several error constants (e.g., ERR_NOT_FOUND, ERR_NOT_ALLOWED, ERR_TYPE_MISMATCH) for consistent error identification.
  • Modified to_js_error to perform io::Error downcasting and map io::ErrorKind variants to the newly defined error constants, providing more descriptive JS error messages.
• crates/utoo-wasm/src/pack.rs
  • Removed a tracing::info! log statement that reported the completion status of pack tasks, simplifying logging output.
• next.js
  • Updated the next.js git submodule to a newer commit (7544553479dd).
• packages/utoo-web/src/utoo/index.d.ts
  • Added export function declarations for the new error constants (e.g., ERR_ABORT, ERR_INVALID_STATE) to the TypeScript definition file.
  • Adjusted the InitOutput interface to include the newly exported error constant functions and reordered some existing readonly properties.
• packages/utoo-web/src/webpackLoaders/cjs.ts
  • Defined a RESOLUTION_EXTENSIONS array to standardize module resolution extensions, including .cjs.
  • Modified loadModule to gracefully handle fs.readFileSync errors during cached ID checks.
  • Implemented a new logic to match module IDs in importMaps by stripping potential random prefixes from absolute paths.
  • Expanded module resolution candidates for mainField and general fallbacks to include .cjs and /index.cjs extensions.
  • Enhanced the error message for unfound dependencies with additional debugging information like importMaps count, CWD, and sample importMaps keys.
• packages/utoo-web/src/webpackLoaders/polyfills/fsPolyfill/utils.ts
  • Imported the new error constants from the utoo WASM module.
  • Extended the translateError function to map various tokio-fs-ext error messages (identified by the new constants) to specific Node.js errno and code values, such as EISDIR, EAGAIN, EACCES, ENOSPC, EINVAL, and EINTR.

Activity

• No specific activity (comments, reviews, approvals) has been recorded for this pull request 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 updates the tokio-fs-ext dependency version from 0.7.3 to 0.7.5 in Cargo.toml and Cargo.lock. It also introduces a macro define_error_consts in crates/utoo-wasm/src/errors.rs to define JavaScript error constants and their corresponding getter functions, and modifies the to_js_error function to map io::ErrorKind to JS error strings. Additionally, the pull request modifies packages/utoo-web/src/utoo/index.d.ts to export the error constants and updates packages/utoo-web/src/webpackLoaders/cjs.ts to improve module resolution, including handling of absolute paths and node_modules. The packages/utoo-web/src/webpackLoaders/polyfills/fsPolyfill/utils.ts file was modified to translate errors. Finally, the next.js subproject commit was updated. The reviewer suggested handling io::ErrorKind::AlreadyExists in the to_js_error function and refactoring the duplicated key sanitization logic in packages/utoo-web/src/webpackLoaders/cjs.ts.

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260209_181125
Generated: 2026-02-09 18:11:25
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	10,014.2 ms	Baseline
Total Thread Work	84,082.8 ms	~8.4x parallelism
Thread Utilization	167.9%	✅ Good
turbo_tasks::function Invocations	3,542,622	Total count
Meaningful Tasks (≥ 10µs)	1,384,969	(39.1% of total)
Tracing Noise (< 10µs)	2,157,653	(60.9% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	942,784	51,282.8	61.0%
P1: I/O & Heavy Tasks	36,297	3,168.8	3.8%
P3: Asset Pipeline	29,596	4,899.1	5.8%
P4: Bridge/Interop	0	0.0	0.0%
Other	376,292	17,811.4	21.2%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	5
Total Thread Work	84,082.8 ms
Avg Work per Thread	16,816.6 ms
Theoretical Parallelism	8.40x
Thread Utilization	167.9%

Assessment: With 5 threads available, achieving 8.4x 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
42,161.1	778,525	54.2	50.1%	turbo_tasks::function
7,749.1	123,557	62.7	9.2%	task execution completed
6,645.3	79,068	84.0	7.9%	turbo_tasks::resolve_call
2,826.0	33,415	84.6	3.4%	analyze ecmascript module
1,947.2	60,868	32.0	2.3%	resolving
1,774.4	13,506	131.4	2.1%	process parse result
1,771.4	45,587	38.9	2.1%	precompute code generation
1,603.3	25,354	63.2	1.9%	effects processing
1,584.8	28,130	56.3	1.9%	module
1,128.5	6,208	181.8	1.3%	parse ecmascript
1,047.3	33,568	31.2	1.2%	internal resolving
824.8	29,570	27.9	1.0%	process module
793.9	27,660	28.7	0.9%	resolve_relative_request
649.9	1,925	337.6	0.8%	analyze variable values
495.2	1,936	255.8	0.6%	generate source map
481.0	15,210	31.6	0.6%	resolve_module_request
474.5	17,366	27.3	0.6%	handle_after_resolve_plugins
448.1	1,954	229.3	0.5%	swc_parse
375.8	10,307	36.5	0.4%	code generation
356.4	16,824	21.2	0.4%	resolved

---

🔍 Deep Dive by Tier

🔴 Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

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

Potential P0 Issues:

• Low thread utilization (167.9%) suggests critical path serialization or lock contention.
• 2,157,653 tasks < 10µs (60.9%) 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,168.8 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,899.1 ms	5.8% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

Problem: 167.9% 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	60.9% of tasks < 10µs
Thread Utilization (P0)	✅ Good	167.9% utilization
Heavy Monoliths (P1)	⚠️ Detected	16 tasks > 100ms
Asset Pipeline (P3)	🔍 Review	4,899.1 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-09
Following: Utoopack Performance Analysis Agent Protocol