feat(pack): support write to dir out of dist

[xusd320]

1. support write assets to dir out of dist
2. support individual custom html output.path
3. add a persistentCaching config

[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 significantly enhances the build system's flexibility by allowing greater control over output locations and caching. It enables assets to be written to arbitrary directories and provides a mechanism for individual HTML files to define their own output paths. Additionally, a new persistentCaching configuration option has been introduced, offering more granular control over build performance and resource utilization.

Highlights

• Flexible Asset Output: Enabled the ability to write compiled assets to directories located outside of the default 'dist' folder.
• Custom HTML Output Paths: Introduced support for specifying individual custom output paths for HTML files.
• Persistent Caching Configuration: Added a new 'persistentCaching' configuration option to control caching behavior.

Changelog

• crates/pack-api/src/app.rs
  • Removed redundant initialization of server_paths and client_paths vectors.
  • Refactored webpack stats generation logic to conditionally process output assets based on should_create_webpack_stats.
• crates/pack-api/src/library.rs
  • Removed redundant initialization of server_paths and client_paths vectors for library endpoints.
• crates/pack-core/src/emit.rs
  • Modified the emit_assets function signature to mark node_root as unused.
  • Updated asset emission logic to allow assets to be written to paths outside the node_root (dist) directory.
• crates/pack-napi/src/pack_api/project.rs
  • Updated tracing subscriber configuration to conditionally enable target and span events based on the presence of an EnvFilter.
• packages/pack-shared/src/config.ts
  • Added an optional output.path property to the HtmlConfig interface, allowing custom output directories for HTML files.
• packages/pack/package.json
  • Updated the domparser-rs dependency from version 0.0.5 to 0.0.7.
• packages/pack/src/commands/build.ts
  • Configured persistentCaching for the build command to respect user-defined settings or default to true.
• packages/pack/src/core/hmr.ts
  • Configured persistentCaching for Hot Module Replacement (HMR) to respect user-defined settings or default to false.
• packages/pack/src/plugins/HtmlPlugin.ts
  • Modified the HTML file writing mechanism to utilize the custom html.output.path if specified in the configuration.
• packages/pack/src/utils/htmlEntry.ts
  • Enhanced HTML entry processing to merge existing entry properties and HTML configuration when creating new entries.

Activity

• No human activity has been recorded on this pull request yet.

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 several useful features: support for writing assets outside the dist directory, custom output paths for individual HTML files, and a persistentCaching configuration option. The changes are generally well-implemented. I've found one potential bug in the HTML entry processing logic when an HTML file has multiple module scripts, and I've suggested a fix. Otherwise, the code looks good.

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260212_101806
Generated: 2026-02-12 10:18:06
Trace File: trace_antd.json (0.5GB, 3.18M events)
Test Project: examples/with-antd

---

Executive Summary

Key Findings

Metric	Value	Assessment
Total Wall Time	8,245.9 ms	Baseline
Total Thread Work (de-duped)	25,676.3 ms	Non-overlapping busy time
Effective Parallelism	3.1x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	62.3%	🆗 Average
Total Spans	1,590,897	All B/E + X events
Meaningful Spans (>= 10us)	528,640	(33.2% of total)
Tracing Noise (< 10us)	1,062,257	(66.8% of total)

Note on Thread Work: Thread work is computed by merging overlapping intervals
per thread, eliminating double-counting from nested spans. This gives the true
wall-clock busy time across all threads.

Workload Distribution by Tier

Category	Tasks	Total Time (ms)	% of Thread Work
P0: Runtime/Resolution	0	0.0	0.0%
P1: I/O & Heavy Tasks	39,067	3,526.3	13.7%
P3: Asset Pipeline	29,456	3,517.1	13.7%
P4: Bridge/Interop	0	0.0	0.0%
Other	460,117	21,891.3	85.3%

Note: Percentages may sum to >100% because task durations include nesting
while thread work is de-duplicated. This is intentional for hotspot attribution.

---

Parallelization Analysis

Thread Utilization

Metric	Value
Working Threads	5
Total Thread Work (de-duped)	25,676.3 ms
Avg Work per Thread	5,135.3 ms
Effective Parallelism	3.11x
Thread Utilization	62.3%

Assessment: With 5 working threads, achieving 3.1x parallelism indicates significant loss of potential parallelism.

---

Top 20 Tasks by Total Duration

Total (ms)	Count	Avg (us)	Max (ms)	% Work	Task Name
8,258.0	188,897	43.7	33.4	32.2%	module
3,977.4	72,624	54.8	185.1	15.5%	process module
3,444.8	36,183	95.2	185.0	13.4%	analyze ecmascript module
2,920.0	24,905	117.2	96.1	11.4%	code generation
1,833.4	60,023	30.5	11.2	7.1%	resolving
1,827.6	64,330	28.4	9.9	7.1%	internal resolving
1,527.0	14,338	106.5	56.5	5.9%	chunking
1,416.9	32,063	44.2	11.0	5.5%	precompute code generation
1,296.2	13,998	92.6	139.3	5.0%	compute async module info
1,054.6	8,082	130.5	42.2	4.1%	parse ecmascript
559.7	4,991	112.1	51.3	2.2%	compute async chunks
296.7	1,936	153.3	18.0	1.2%	generate source map
78.0	698	111.7	21.6	0.3%	compute binding usage info
69.6	2,165	32.1	0.4	0.3%	read file
65.6	1,872	35.0	15.3	0.3%	collect mergeable modules
63.9	578	110.6	11.2	0.2%	async reference
62.6	103	607.8	17.4	0.2%	make production chunks
39.9	15	2662.1	12.7	0.2%	apply effects
39.4	13	3029.1	12.7	0.2%	write file
33.4	3	11124.4	16.6	0.1%	compute merged modules

---

Deep Dive by Tier

Tier 1: Runtime & Resolution (P0)

Focus: Task scheduling and dependency resolution.

Metric	Value	Status
Total Scheduling Time	0.0 ms	✅ Normal
Resolution Hotspots	0 distinct task types	Check Top Tasks

Potential P0 Issues:

• Thread utilization at 62.3% suggests critical path serialization or lock contention.
• 1,062,257 spans < 10us (66.8%) 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,526.3 ms	✅ Healthy
Large Tasks (> 100ms)	3	Minimal

Tier 3: Architecture & Asset Pipeline (P2-P3)

Focus: Global state and transformation pipeline.

Metric	Value	Status
Asset Processing (P3)	3,517.1 ms	13.7% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,062,257	66.8%
10us - 100us	502,513	31.6%
100us - 1ms	22,066	1.4%
1ms - 10ms	3,966	0.2%
10ms - 100ms	92	0.0%
> 100ms	3	0.0%

---

Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	⚠️ Significant	66.8% of spans < 10us
Thread Utilization (P0)	🆗 Average	62.3% utilization
Heavy Monoliths (P1)	✅ Minimal	3 tasks > 100ms
Asset Pipeline (P3)	Review	3,517.1 ms total
Bridge/Interop (P4)	Low	0.0 ms total

---

Action Items (P0-P4)

1. [P0] Profile lock contention to address 37% 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-02-12
Following: Utoopack Performance Analysis Agent Protocol

[xusd320]

@copilot ci 为什么一直 pending

[Copilot]

@xusd320 I've opened a new pull request, #2597, to work on those changes. Once the pull request is ready, I'll request review from you.