fix: registry url

[elrrrrrrr]

• 🧶 Normalize the registry URL by reqwest exp: https://registry.npmmirror.com/////
• 🤖 No modifications to existing configuration files
• ♻️ Only applies configuration in-memory

cc @yuzheng14

[gemini-code-assist]

Summary of Changes

Hello @elrrrrrrr, 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 improves the reliability of registry URL handling within the application. By introducing URL normalization and propagating potential errors through Result types, it ensures that registry URLs are consistently formatted and that any issues during their parsing are properly managed, leading to a more stable and predictable system for package management.

Highlights

• Registry URL Normalization: Implemented robust registry URL normalization using reqwest::Url to ensure consistent URL formats, such as adding trailing slashes, for all registry interactions.
• Enhanced Error Handling: Improved error handling by updating several core functions (Context::registry, set_registry, UnifiedRegistryBuilder::build) to return Result types, allowing for proper propagation of potential URL parsing errors throughout the application.
• In-memory Configuration: Ensured that all registry configuration changes, including URL normalization, are applied in-memory and do not modify any persistent configuration files.

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 correctly implements registry URL normalization using reqwest::Url. The changes to function signatures to return Result and the propagation of errors using ? are well-executed throughout the codebase. I've added a couple of suggestions to improve code style and test failure diagnostics. Overall, this is a solid improvement.

[github-actions]

📊 Performance Benchmark Report (with-antd)

🚀 Utoopack Performance Report: Async Task Scheduling Overhead Analysis

Report ID: utoopack_performance_report_20260128_025013
Generated: 2026-01-28 02:50:13
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,525.0 ms	Baseline
Total Thread Work	89,977.3 ms	~8.5x parallelism
Thread Utilization	57.0%	⚠️ Suboptimal
turbo_tasks::function Invocations	3,881,520	Total count
Meaningful Tasks (≥ 10µs)	1,546,798	(39.9% of total)
Tracing Noise (< 10µs)	2,334,722	(60.1% of total)

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Work
P0: Runtime/Resolution	1,062,775	54,739.8	60.8%
P1: I/O & Heavy Tasks	37,876	3,617.0	4.0%
P3: Asset Pipeline	28,130	4,392.2	4.9%
P4: Bridge/Interop	0	0.0	0.0%
Other	418,017	19,953.0	22.2%

---

⚡ Parallelization Analysis (P0-P2)

Thread Utilization

Metric	Value
Number of Threads	15
Total Thread Work	89,977.3 ms
Avg Work per Thread	5,998.5 ms
Theoretical Parallelism	8.55x
Thread Utilization	57.0%

Assessment: With 15 threads available, achieving 8.5x 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,427.3	881,662	51.5	50.5%	turbo_tasks::function
8,477.4	124,435	68.1	9.4%	task execution completed
6,633.0	85,030	78.0	7.4%	turbo_tasks::resolve_call
3,009.3	32,940	91.4	3.3%	analyze ecmascript module
2,232.0	67,411	33.1	2.5%	precompute code generation
2,043.0	68,178	30.0	2.3%	resolving
1,812.9	35,905	50.5	2.0%	module
1,753.3	20,888	83.9	1.9%	effects processing
1,574.4	11,695	134.6	1.7%	process parse result
1,167.7	32,916	35.5	1.3%	process module
1,107.2	6,561	168.8	1.2%	parse ecmascript
1,072.3	36,015	29.8	1.2%	internal resolving
906.2	29,010	31.2	1.0%	resolve_relative_request
631.1	1,916	329.4	0.7%	analyze variable values
483.7	20,650	23.4	0.5%	handle_after_resolve_plugins
473.1	15,741	30.1	0.5%	resolve_module_request
445.8	10,995	40.5	0.5%	code generation
409.8	1,943	210.9	0.5%	swc_parse
395.7	17,729	22.3	0.4%	resolved
336.5	4,233	79.5	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	54,739.8 ms	⚠️ High
Resolution Hotspots	9 tasks	🔍 Check Top Tasks

Potential P0 Issues:

• Low thread utilization (57.0%) suggests critical path serialization or lock contention.
• 2,334,722 tasks < 10µs (60.1%) 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,617.0 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,392.2 ms	4.9% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

💡 Recommendations (Prioritized P0-P2)

🚨 Critical: (P0) Improvement

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

---

🎯 Action Items (Comprehensive P0-P4)

1. [P0] Profile lock contention to address 43% 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