feat(pack): add devServer.proxy with pathRewrite and example

[yuzheng14]

Summary

Implements devServer.proxy for Utoo Pack dev server.

Changes

• pack-shared: ProxyRule, DevServerProxy, PathRewrite types; proxyFromObject util; devServer.proxy on config.
• pack: core/proxy.ts — context match (prefix + ^ regex), pathRewrite (object + function), changeOrigin/secure; wired into HTTP and WebSocket in dev.ts.
• Tests: __test__/utils.test.ts, __test__/proxy.test.ts (excluded from tsconfig).
• Example: examples/with-proxy — React app proxying to JSONPlaceholder via /api and /placeholder.

Closes #2584

Made with Cursor

[gemini-code-assist]

Summary of Changes

Hello, 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 the highly anticipated devServer.proxy feature to the Utoo Pack development server. This enhancement allows developers to seamlessly proxy API requests and WebSocket connections to external backend services, effectively bypassing CORS issues during development. The implementation includes flexible path rewriting capabilities and options for managing origin headers and SSL security, significantly improving the development workflow for applications interacting with separate backend APIs.

Highlights

• Dev Server Proxy Implementation: Implemented devServer.proxy functionality for the Utoo Pack dev server, enabling requests to be forwarded to a target server.
• Path Rewriting and Options: Introduced PathRewrite options, supporting both object and function forms to modify request paths, along with changeOrigin and secure options for proxy rules.
• HTTP and WebSocket Integration: Integrated proxy handling for both HTTP and WebSocket requests within the dev server's request processing.
• New Example Project: Created a new example project (examples/with-proxy) to demonstrate the configuration and usage of the devServer.proxy feature.
• Configuration Utility: Developed the proxyFromObject utility to convert object-style proxy configurations into an array of ProxyRule objects for easier processing.
• Testing and Build Configuration: Added dedicated test files for the proxyFromObject utility and the dev server proxy integration, and updated TypeScript configurations to exclude test directories.

Changelog

• .vscode/settings.json
  • Changed default JavaScript and TypeScript formatter to Biome.
• Cargo.lock
  • Added turbopack-css as a dependency.
• examples/with-proxy/.gitignore
  • Added a new .gitignore file for the with-proxy example.
• examples/with-proxy/index.html
  • Added a new index.html file for the with-proxy example.
• examples/with-proxy/package.json
  • Added a new package.json file for the with-proxy example, including React dependencies and Utoo Pack CLI.
• examples/with-proxy/src/App.tsx
  • Added a new React component (App.tsx) demonstrating proxy usage with jsonplaceholder.typicode.com.
• examples/with-proxy/src/index.tsx
  • Added a new entry point (index.tsx) for the with-proxy example.
• examples/with-proxy/utoopack.json
  • Added a new Utoo Pack configuration file (utoopack.json) for the with-proxy example, defining proxy rules.
• packages/pack-shared/src/test/utils.test.ts
  • Added a new test file for the proxyFromObject utility.
• packages/pack-shared/src/config.ts
  • Defined new types PathRewrite, ProxyRule, DevServerProxy, and ProxyOptions for proxy configuration.
  • Extended DevServerConfig to include a proxy option.
• packages/pack-shared/src/utils.ts
  • Imported new proxy-related types.
  • Added the proxyFromObject utility function.
• packages/pack-shared/tsconfig.json
  • Excluded the src/__test__ directory from TypeScript compilation.
• packages/pack/src/test/proxy.test.ts
  • Added a new test file for the dev server proxy integration.
• packages/pack/src/commands/dev.ts
  • Imported handleProxyRequest and handleProxyUpgrade functions.
  • Integrated proxy handling into the HTTP request and WebSocket upgrade logic of the dev server.
• packages/pack/src/core/proxy.ts
  • Added a new file containing core proxy logic, including functions for path rewriting, context matching, and handling HTTP/WebSocket proxy requests.
• packages/pack/tsconfig.json
  • Excluded the src/__test__ directory from TypeScript compilation.

Activity

• No human activity (comments, reviews, approvals) was detected on this pull request.

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 devServer.proxy feature, which is a valuable addition for development workflows. The implementation is comprehensive, including new configuration types, core proxying logic using http-proxy, and integration into the dev server for both HTTP and WebSocket requests. The inclusion of a new example project (with-proxy) is excellent for demonstrating the feature's usage. My main feedback is focused on improving the error handling in the proxy logic to make it more robust and prevent potential server errors when a proxy request fails.

[yuzheng14]

现在是基于原生 Node.js 封装的，考虑到后期中间件的需求越来越多，还是需要一个成熟的框架

webpack 选择的 express，vite 选择的 connect（也是 express 的底层）

同时 utoo 很大一部分会考虑到跨平台使用（web nodejs wasm 等），hono 这种不挑运行时的框架可能是个不错的选择

不过由于 hono 是基于 web standard API 封装的，且由于 hono 自身的路由优化，可能需要这个 pr 先重构成 hono 的形式，以获得更好的性能。

[yuzheng14]

由于 hono 的 nodejs adapter 的封装问题，先给 ws 代理功能砍了，地址正则匹配功能留下来了

[fireairforce]

@yuzheng14 it seems conflict

[fireairforce]

这个还是用 turbo run test 吧，给 pack-shared 和 pack 这两个包都加个 test 脚本就好了

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260320_091901
Generated: 2026-03-20 09:19:01
Trace File: trace_antd.json (0.6GB, 1.63M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	8,489.0 ms	Baseline
Total Thread Work (de-duped)	27,561.8 ms	Non-overlapping busy time
Effective Parallelism	3.2x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	64.9%	🆗 Average
Total Spans	1,632,802	All B/E + X events
Meaningful Spans (>= 10us)	564,015	(34.5% of total)
Tracing Noise (< 10us)	1,068,787	(65.5% of total)

---

Build Phase Timeline

Shows when each build phase is active and how much CPU it consumes.
Self-Time is the time spent exclusively in that phase (excluding children).

Phase	Spans	Inclusive (ms)	Self-Time (ms)	Wall Range (ms)
Resolve	126,377	3,418.5	2,735.8	5,109.2
Parse	10,111	1,108.7	1,047.7	8,334.2
Analyze	331,150	17,639.9	13,087.1	7,931.0
Chunk	26,684	2,052.2	1,880.9	2,301.3
Codegen	60,319	4,501.3	3,320.7	2,004.4
Emit	27	66.6	32.4	16.9
Other	9,347	1,197.9	1,066.1	8,489.0

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	465,441	22,132.2	80.3%	16,772.5	60.9%
P1: I/O & Heavy Tasks	2,782	137.0	0.5%	102.8	0.4%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	95,689	7,668.1	27.8%	6,255.2	22.7%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	103	47.9	0.2%	40.2	0.1%

---

Top 20 Tasks by Self-Time

Self-time is the exclusive duration: time spent in the task itself, not in sub-tasks.
This is the most accurate indicator of where CPU cycles are actually spent.

Self (ms)	Inclusive (ms)	Count	Avg Self (us)	P95 Self (ms)	Max Self (ms)	% Work	Task Name	Top Caller
7,467.0	8,423.8	208,954	35.7	0.1	12.0	27.1%	module	write all entrypoints to disk (1%)
2,898.4	3,763.0	36,098	80.3	0.2	244.4	10.5%	analyze ecmascript module	process module (76%)
1,640.6	2,821.2	24,779	66.2	0.2	71.3	6.0%	code generation	chunking (6%)
1,478.4	1,597.1	58,125	25.4	0.0	9.0	5.4%	internal resolving	resolving (31%)
1,380.0	4,081.8	69,884	19.7	0.0	7.4	5.0%	process module	module (16%)
1,364.1	1,364.1	33,624	40.6	0.1	9.0	4.9%	precompute code generation	code generation (30%)
1,256.2	1,399.6	15,211	82.6	0.2	54.4	4.6%	chunking	write all entrypoints to disk (0%)
1,249.1	1,813.0	67,621	18.5	0.0	7.4	4.5%	resolving	module (31%)
1,209.0	1,209.0	13,642	88.6	0.4	119.2	4.4%	compute async module info	chunking (0%)
998.3	1,117.5	8,599	116.1	0.0	260.1	3.6%	write all entrypoints to disk	None (0%)
985.7	1,046.7	7,987	123.4	0.5	35.7	3.6%	parse ecmascript	analyze ecmascript module (26%)
595.9	596.6	11,264	52.9	0.1	43.2	2.2%	compute async chunks	compute async chunks (0%)
316.0	316.0	1,916	164.9	0.4	32.2	1.1%	generate source map	code generation (96%)
67.9	67.9	699	97.1	0.0	17.5	0.2%	compute binding usage info	write all entrypoints to disk (1%)
60.3	60.3	2,113	28.5	0.0	0.9	0.2%	read file	parse ecmascript (93%)
50.7	50.7	1,850	27.4	0.0	7.7	0.2%	collect mergeable modules	compute merged modules (0%)
32.2	32.2	13	2475.4	8.9	10.6	0.1%	write file	apply effects (100%)
28.8	56.1	209	138.0	0.3	16.3	0.1%	make production chunks	chunking (2%)
27.6	32.4	645	42.8	0.1	3.1	0.1%	async reference	write all entrypoints to disk (1%)
16.6	16.6	4	4141.2	10.5	11.8	0.1%	blocking	map chunk groups (25%)

---

Critical Path Analysis

The longest sequential dependency chains that determine wall-clock time.
Focus on reducing the depth of these chains to improve parallelism.

Rank	Self-Time (ms)	Depth	Path
1	244.5	2	process module → analyze ecmascript module
2	92.1	2	code generation → generate source map
3	83.0	2	process module → analyze ecmascript module
4	81.0	2	code generation → generate source map
5	59.9	2	process module → analyze ecmascript module

---

Batching Candidates

High-volume tasks dominated by a single parent. If the parent can batch them,
it drastically reduces scheduler overhead.

Task Name	Count	Top Caller (Attribution)	Avg Self	P95 Self	Total Self
analyze ecmascript module	36,098	process module (76%)	80.3 us	0.17 ms	2,898.4 ms

---

Duration Distribution

Range	Count	Percentage
<10us	1,068,787	65.5%
10us-100us	537,084	32.9%
100us-1ms	22,554	1.4%
1ms-10ms	4,272	0.3%
10ms-100ms	100	0.0%
>100ms	5	0.0%

---

Action Items

1. [P0] Focus on tasks with the highest Self-Time — these are where CPU cycles are actually spent.
2. [P0] Use Batching Candidates to identify callers that should use try_join or reduce #[turbo_tasks::function] granularity.
3. [P1] Check Build Phase Timeline for phases with disproportionate wall range vs. self-time (= serialization).
4. [P1] Inspect P95 Self (ms) for heavy monolith tasks. Focus on long-tail outliers, not averages.
5. [P1] Review Critical Paths — reducing the longest chain depth directly improves wall-clock time.
6. [P2] If Thread Utilization < 60%, investigate scheduling gaps (lock contention or deep dependency chains).

Report generated by Utoopack Performance Analysis Agent