feat(web): add Project.checkCompatibility API

[xusd320]

This PR adds a static checkCompatibility method to the Project class in @utoo/web.

It verifies if the browser environment supports essential features like:

• SharedArrayBuffer (with crossOriginIsolated)
• Atomics
• Worker
• ServiceWorker
• OPFS
• FileSystemObserver

This allows applications to fail fast or show warnings if the environment is not compatible.

[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 introduces a new browser compatibility check API within the @utoo/web library. This allows applications to programmatically determine if the current browser environment supports a set of essential web features required for optimal functionality. By providing a clear compatibility report, applications can proactively inform users or adapt their behavior, preventing potential runtime issues and enhancing the overall user experience.

Highlights

• New Compatibility API: Introduced a static checkCompatibility method to the Project class in @utoo/web.
• Feature Verification: The new API verifies browser support for critical features such as SharedArrayBuffer (with crossOriginIsolated), Atomics, Worker, ServiceWorker, OPFS, and FileSystemObserver.
• Detailed Report: The method returns an object indicating overall compatibility, a minimal Chrome version, detailed status for each feature, and a list of missing features.

Changelog

• Cargo.lock
  • Added thiserror dependency.
• packages/utoo-web/src/project/Project.ts
  • Imported checkCompatibility function.
  • Added a static checkCompatibility method to the Project class.
• packages/utoo-web/src/project/checkCompatibility.ts
  • Created a new file to house the checkCompatibility function.

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 checkCompatibility API to verify if the browser environment supports a set of required features. The implementation is well-structured in a new checkCompatibility.ts file and exposed via a static method on the Project class.

My review focuses on improving the maintainability and clarity of the new checkCompatibility function. I've suggested extracting the return type into a named interface, refactoring the logic for identifying missing features to be more data-driven, and clarifying the hardcoded minimal Chrome version. These changes should make the new API easier to understand and extend in the future.

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260210_103314
Generated: 2026-02-10 10:33:14
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,946.2 ms	Baseline
Total Thread Work	79,506.6 ms	~8.9x parallelism
Thread Utilization	177.7%	✅ Good
turbo_tasks::function Invocations	3,542,091	Total count
Meaningful Tasks (≥ 10µs)	1,301,986	(36.8% of total)
Tracing Noise (< 10µs)	2,240,105	(63.2% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	877,379	47,520.6	59.8%
P1: I/O & Heavy Tasks	35,390	3,080.4	3.9%
P3: Asset Pipeline	28,703	4,022.0	5.1%
P4: Bridge/Interop	0	0.0	0.0%
Other	360,514	17,560.5	22.1%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	5
Total Thread Work	79,506.6 ms
Avg Work per Thread	15,901.3 ms
Theoretical Parallelism	8.89x
Thread Utilization	177.7%

Assessment: With 5 threads available, achieving 8.9x 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,725.1	727,943	54.6	50.0%	turbo_tasks::function
8,226.1	124,152	66.3	10.3%	task execution completed
5,486.3	69,508	78.9	6.9%	turbo_tasks::resolve_call
2,592.0	32,532	79.7	3.3%	analyze ecmascript module
1,856.9	59,561	31.2	2.3%	resolving
1,652.7	26,510	62.3	2.1%	module
1,507.4	40,472	37.2	1.9%	precompute code generation
1,484.8	24,536	60.5	1.9%	effects processing
1,400.6	12,928	108.3	1.8%	process parse result
976.0	6,146	158.8	1.2%	parse ecmascript
909.2	32,458	28.0	1.1%	internal resolving
773.8	25,946	29.8	1.0%	process module
757.0	26,508	28.6	1.0%	resolve_relative_request
567.2	1,917	295.9	0.7%	analyze variable values
472.2	14,589	32.4	0.6%	resolve_module_request
402.8	14,552	27.7	0.5%	handle_after_resolve_plugins
380.5	1,941	196.1	0.5%	swc_parse
372.9	1,936	192.6	0.5%	generate source map
354.4	16,406	21.6	0.4%	resolved
337.5	2,167	155.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	47,520.6 ms	⚠️ High
Resolution Hotspots	9 tasks	🔍 Check Top Tasks

Potential P0 Issues:

• Low thread utilization (177.7%) suggests critical path serialization or lock contention.
• 2,240,105 tasks < 10µs (63.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,080.4 ms	✅ Healthy
Large Tasks (> 100ms)	13	🚨 Critical

Potential P1 Issues:

• 13 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,022.0 ms	5.1% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

Problem: 177.7% thread utilization.
Action:

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

⚠️ High Priority: (P1) Optimization

Problem: 13 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.2% of tasks < 10µs
Thread Utilization (P0)	✅ Good	177.7% utilization
Heavy Monoliths (P1)	⚠️ Detected	13 tasks > 100ms
Asset Pipeline (P3)	🔍 Review	4,022.0 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