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 代理功能砍了，地址正则匹配功能留下来了

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260317_064528
Generated: 2026-03-17 06:45:28
Trace File: trace_antd.json (0.6GB, 1.66M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	10,016.7 ms	Baseline
Total Thread Work (de-duped)	31,897.6 ms	Non-overlapping busy time
Effective Parallelism	3.2x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	63.7%	🆗 Average
Total Spans	1,659,320	All B/E + X events
Meaningful Spans (>= 10us)	639,197	(38.5% of total)
Tracing Noise (< 10us)	1,020,123	(61.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	143,388	4,220.4	3,400.2	5,760.4
Parse	10,363	1,409.6	1,322.4	9,823.6
Analyze	374,149	20,357.2	14,995.7	9,314.9
Chunk	29,887	2,571.7	2,343.0	2,813.7
Codegen	71,375	5,300.2	3,933.5	2,441.1
Emit	27	71.4	35.6	16.8
Other	10,008	1,748.2	1,560.2	10,016.7

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	525,679	26,124.1	81.9%	19,764.6	62.0%
P1: I/O & Heavy Tasks	2,924	173.2	0.5%	137.4	0.4%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	110,458	9,318.2	29.2%	7,635.7	23.9%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	136	63.2	0.2%	53.1	0.2%

---

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
8,320.7	9,458.9	234,350	35.5	0.1	9.4	26.1%	module	write all entrypoints to disk (1%)
3,252.7	4,344.9	38,758	83.9	0.2	187.1	10.2%	analyze ecmascript module	process module (75%)
1,886.2	2,038.6	66,415	28.4	0.0	27.1	5.9%	internal resolving	resolving (30%)
1,871.7	3,238.4	26,171	71.5	0.2	50.3	5.9%	code generation	chunking (7%)
1,726.2	4,816.9	79,569	21.7	0.0	7.1	5.4%	process module	module (16%)
1,698.5	1,698.5	43,267	39.3	0.1	8.2	5.3%	precompute code generation	code generation (25%)
1,501.6	2,169.5	76,251	19.7	0.0	7.4	4.7%	resolving	module (34%)
1,497.4	1,686.9	16,560	90.4	0.2	78.2	4.7%	chunking	write all entrypoints to disk (0%)
1,489.7	1,489.7	18,566	80.2	0.3	194.1	4.7%	compute async module info	chunking (0%)
1,452.7	1,625.9	9,150	158.8	0.0	379.9	4.6%	write all entrypoints to disk	None (0%)
1,233.0	1,320.1	8,188	150.6	0.6	67.1	3.9%	parse ecmascript	analyze ecmascript module (27%)
798.8	799.6	13,074	61.1	0.1	66.8	2.5%	compute async chunks	write all entrypoints to disk (0%)
363.3	363.3	1,937	187.6	0.5	28.9	1.1%	generate source map	code generation (96%)
126.1	126.1	1,008	125.1	0.1	29.9	0.4%	compute binding usage info	write all entrypoints to disk (0%)
89.3	89.3	2,166	41.2	0.1	7.1	0.3%	read file	parse ecmascript (91%)
64.1	64.1	1,875	34.2	0.0	8.6	0.2%	collect mergeable modules	compute merged modules (0%)
54.4	59.1	722	75.3	0.1	4.1	0.2%	async reference	write all entrypoints to disk (1%)
46.9	85.2	253	185.5	0.2	30.8	0.1%	make production chunks	chunking (2%)
35.3	35.3	13	2713.3	10.2	12.4	0.1%	write file	apply effects (100%)
18.0	18.0	4	4499.4	11.2	12.5	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	187.2	2	process module → analyze ecmascript module
2	69.1	2	code generation → generate source map
3	67.2	2	analyze ecmascript module → parse ecmascript
4	65.6	2	process module → analyze ecmascript module
5	49.2	2	code generation → generate source map

---

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	38,758	process module (75%)	83.9 us	0.20 ms	3,252.7 ms

---

Duration Distribution

Range	Count	Percentage
<10us	1,020,123	61.5%
10us-100us	607,242	36.6%
100us-1ms	26,630	1.6%
1ms-10ms	5,207	0.3%
10ms-100ms	111	0.0%
>100ms	7	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

[fireairforce]

@yuzheng14 it seems conflict

[fireairforce]

这个 vitest 配置要不在顶层放一个，然后去对应的每个 packages/** 里面去单独放一个？这样顶层 turbo 驱动 turbo test 的时候可以缓存每一次的 vitest 结果，也方便后面这个 monorepo 去添加新的子应用

[fireairforce]

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