chore(pack): add alias with : test case

[fireairforce]

Summary

alias like: smallfish:runtime will be recognize as schema path not alias under webpack.

add a test case for utoopack, it looks fine.

Test Plan

[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 a new test case to validate the handling of module aliases that contain colons, such as smallfish:runtime. This ensures that the build system correctly interprets these as aliases rather than schema paths, preventing potential resolution issues. The changes involve adding new configuration, test modules, and snapshot tests to confirm the expected behavior and error reporting.

Highlights

• New Alias Test Case: Added a new alias smallfish:runtime to the config.json to specifically test alias resolution for patterns containing colons, which can sometimes be misinterpreted as schema paths.
• Module Creation: Introduced two new test modules, runtime.ts and x.ts, to support the new alias test case and demonstrate module import behavior.
• Import and Usage Updates: Modified index.ts to import and use the newly aliased smallfish:runtime module, as well as x.ts, to validate the alias resolution and module loading.
• Warning Snapshot Test: Included a snapshot test (Export-notFound-doesn-t-exist-in-target-module-942f39.txt) to capture and assert an expected warning when attempting to import a non-existent export (notFound) from x.ts, ensuring correct error reporting.
• Output File Updates: The generated JavaScript output and its corresponding sourcemap were updated and renamed to reflect the inclusion of the new modules and the changes in the test setup.

Changelog

• crates/pack-tests/tests/snapshot/basic/alias/config.json
  • Added a new alias entry "smallfish:runtime": "./input/runtime.ts" to the alias configuration.
• crates/pack-tests/tests/snapshot/basic/alias/input/index.ts
  • Added import statements for runtime from smallfish:runtime and notFound from ./x.
  • Included usage of notFound and runtime variables.
• crates/pack-tests/tests/snapshot/basic/alias/input/runtime.ts
  • Added a new file defining export const runtime = "runtime";.
• crates/pack-tests/tests/snapshot/basic/alias/input/x.ts
  • Added a new file defining export const x = 'x';.
• crates/pack-tests/tests/snapshot/basic/alias/issues/Export-notFound-doesn-t-exist-in-target-module-942f39.txt
  • Added a new snapshot file capturing the expected warning for an Export notFound doesn't exist error.
• crates/pack-tests/tests/snapshot/basic/alias/output/_project___63bc685e.js
  • Renamed to _project___de7ba625.js.
  • Included the generated code for runtime.ts and x.ts modules.
  • Updated import paths to reflect the new modules.
• crates/pack-tests/tests/snapshot/basic/alias/output/_project___63bc685e.js.map
  • Renamed to _project___de7ba625.js.map.
  • Updated source map entries to include runtime.ts and x.ts.
• crates/pack-tests/tests/snapshot/basic/alias/output/main.js
  • Updated the otherChunks reference to the new output filename _project___de7ba625.js.

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 adds a snapshot test case to verify that aliases containing a colon are handled correctly. The changes are well-structured for a test case, including a new alias configuration, corresponding source files, and an intentional import error to test warning generation. My review identified a minor but important convention violation: several new files are missing a final newline character. I've suggested adding them to ensure file consistency and compatibility with various development tools.

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260316_091853
Generated: 2026-03-16 09:18:53
Trace File: trace_antd.json (0.6GB, 1.66M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	9,178.9 ms	Baseline
Total Thread Work (de-duped)	29,895.9 ms	Non-overlapping busy time
Effective Parallelism	3.3x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	65.1%	🆗 Average
Total Spans	1,659,685	All B/E + X events
Meaningful Spans (>= 10us)	605,809	(36.5% of total)
Tracing Noise (< 10us)	1,053,876	(63.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	137,337	4,046.0	3,257.2	5,501.9
Parse	10,270	1,202.9	1,125.1	9,032.0
Analyze	355,498	19,055.7	14,095.4	8,584.1
Chunk	28,792	2,375.7	2,194.8	2,500.8
Codegen	64,357	4,703.9	3,491.6	2,176.6
Emit	27	66.1	32.9	11.4
Other	9,528	1,464.2	1,317.9	9,178.9

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	500,608	24,406.4	81.6%	18,519.5	61.9%
P1: I/O & Heavy Tasks	2,923	160.0	0.5%	126.9	0.4%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	102,160	8,297.3	27.8%	6,826.2	22.8%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	118	50.9	0.2%	42.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
8,025.2	9,101.3	222,559	36.1	0.1	8.9	26.8%	module	write all entrypoints to disk (1%)
3,088.4	3,991.6	37,918	81.4	0.2	192.0	10.3%	analyze ecmascript module	process module (75%)
1,772.1	1,906.8	64,458	27.5	0.0	8.8	5.9%	internal resolving	resolving (30%)
1,714.4	2,926.7	25,663	66.8	0.2	68.5	5.7%	code generation	chunking (7%)
1,563.4	4,513.2	76,591	20.4	0.0	7.1	5.2%	process module	module (16%)
1,469.7	2,123.8	72,156	20.4	0.0	16.7	4.9%	resolving	module (32%)
1,452.3	1,452.3	36,758	39.5	0.1	10.1	4.9%	precompute code generation	code generation (29%)
1,437.0	1,588.3	15,823	90.8	0.2	74.0	4.8%	chunking	write all entrypoints to disk (0%)
1,255.9	1,388.9	8,793	142.8	0.0	290.5	4.2%	write all entrypoints to disk	None (0%)
1,254.8	1,254.8	15,620	80.3	0.3	147.3	4.2%	compute async module info	chunking (0%)
1,046.5	1,124.3	8,097	129.2	0.5	65.0	3.5%	parse ecmascript	analyze ecmascript module (26%)
720.8	721.7	12,744	56.6	0.1	53.8	2.4%	compute async chunks	compute async chunks (0%)
324.9	324.9	1,936	167.8	0.4	19.0	1.1%	generate source map	code generation (96%)
93.4	93.4	914	102.2	0.0	25.4	0.3%	compute binding usage info	write all entrypoints to disk (0%)
78.6	78.6	2,167	36.2	0.1	3.1	0.3%	read file	parse ecmascript (91%)
58.9	58.9	1,871	31.5	0.0	8.0	0.2%	collect mergeable modules	compute merged modules (0%)
37.0	65.8	225	164.3	0.4	19.4	0.1%	make production chunks	chunking (2%)
32.7	32.7	13	2513.0	9.7	11.1	0.1%	write file	apply effects (100%)
19.8	24.5	617	32.0	0.1	2.4	0.1%	async reference	write all entrypoints to disk (1%)
15.3	15.3	723	21.2	0.0	2.7	0.1%	read directory	internal resolving (100%)

---

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	192.2	2	process module → analyze ecmascript module
2	87.6	2	code generation → generate source map
3	84.1	2	process module → analyze ecmascript module
4	65.1	2	analyze ecmascript module → parse ecmascript
5	52.8	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	37,918	process module (75%)	81.4 us	0.18 ms	3,088.4 ms

---

Duration Distribution

Range	Count	Percentage
<10us	1,053,876	63.5%
10us-100us	576,322	34.7%
100us-1ms	24,652	1.5%
1ms-10ms	4,729	0.3%
10ms-100ms	100	0.0%
>100ms	6	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