feat(pack): allow emit seperate css when building library

[xusd320]

This pull request adds support for customizable chunk filenames in the library chunking context, allowing users to specify a separate filename template for non-evaluate chunks. The changes introduce a new chunk_filename field, update the builder pattern to support it, and modify the chunk path logic to use this template when appropriate.

Chunk filename customization:

• Added a new chunk_filename field to the LibraryChunkingContext struct to store a non-evaluate chunk filename template. [1] [2]
• Updated the LibraryChunkingContextBuilder with a new .chunk_filename() method to set the chunk filename template.
• Modified the chunk path resolution logic in the ChunkingContext implementation to use the chunk_filename template for non-evaluate chunks, including support for name and content hash placeholders. [1] [2]

Integration with library context creation:

• Updated get_library_chunking_context to set both filename and chunk_filename on the builder when in production mode, based on the output configuration.

Hashing utility import:

• Imported the hash_xxh3_hash64 function to support content hash replacement in chunk filenames.

[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 enhances the library chunking context by introducing a dedicated mechanism for customizing filenames of non-evaluate chunks. This allows for more granular control over the output structure, particularly enabling the emission of separate CSS files during library builds, by providing a new 'chunk_filename' template that supports dynamic placeholders like '[name]' and '[contenthash]'.

Highlights

• Customizable Chunk Filenames: Introduced a new 'chunk_filename' field in 'LibraryChunkingContext' to allow specifying a separate filename template for non-evaluate chunks.
• Builder Pattern Update: Added a '.chunk_filename()' method to 'LibraryChunkingContextBuilder' for setting the new chunk filename template.
• Dynamic Chunk Path Resolution: Modified the 'chunk_path' logic to utilize the 'chunk_filename' template for non-evaluate chunks, supporting '[name]' and '[contenthash]' placeholders.
• Production Mode Integration: Updated 'get_library_chunking_context' to apply the 'chunk_filename' from output configuration when in production mode.
• Hashing Utility: Imported 'hash_xxh3_hash64' to enable content hash replacement in chunk filenames.

Changelog

• crates/pack-core/src/library/chunking_context.rs
  • Imported 'hash_xxh3_hash64' and 'AssetContent' for content hashing capabilities.
  • Added a 'chunk_filename' field to the 'LibraryChunkingContext' struct to store the template for non-evaluate chunks.
  • Implemented a 'chunk_filename' method in 'LibraryChunkingContextBuilder' to set this new field.
  • Modified the 'chunk_path' function to conditionally use the 'chunk_filename' template for non-evaluate assets, supporting '[name]' and '[contenthash]' placeholders.
  • Removed a previous bail condition that prevented the generation of non-evaluate chunks.
• crates/pack-core/src/library/contexts.rs
  • Updated 'get_library_chunking_context' to pass the 'chunk_filename' from the output configuration to the 'LibraryChunkingContextBuilder' when not in development mode.

Activity

• No activity has been provided for 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 valuable feature by allowing customizable filenames for non-evaluate chunks, which is particularly useful for emitting separate CSS files. The implementation is solid and follows the intended design. I have one suggestion to refactor a block of code to improve its readability and maintainability by reducing nesting. Overall, great work!

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260212_123337
Generated: 2026-02-12 12:33:37
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	7,972.2 ms	Baseline
Total Thread Work (de-duped)	25,215.7 ms	Non-overlapping busy time
Effective Parallelism	3.2x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	63.3%	🆗 Average
Total Spans	1,590,042	All B/E + X events
Meaningful Spans (>= 10us)	518,121	(32.6% of total)
Tracing Noise (< 10us)	1,071,921	(67.4% 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	38,521	3,396.3	13.5%
P3: Asset Pipeline	29,036	3,251.5	12.9%
P4: Bridge/Interop	0	0.0	0.0%
Other	450,564	21,438.3	85.0%

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,215.7 ms
Avg Work per Thread	5,043.1 ms
Effective Parallelism	3.16x
Thread Utilization	63.3%

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

---

Top 20 Tasks by Total Duration

Total (ms)	Count	Avg (us)	Max (ms)	% Work	Task Name
8,109.6	186,519	43.5	14.0	32.2%	module
3,949.5	70,456	56.1	156.3	15.7%	process module
3,326.9	35,652	93.3	156.2	13.2%	analyze ecmascript module
2,819.5	24,484	115.2	62.1	11.2%	code generation
1,812.1	62,771	28.9	11.0	7.2%	internal resolving
1,773.8	59,014	30.1	11.1	7.0%	resolving
1,417.7	14,320	99.0	45.9	5.6%	chunking
1,386.2	30,549	45.4	13.0	5.5%	precompute code generation
1,268.6	13,534	93.7	131.2	5.0%	compute async module info
959.4	8,054	119.1	38.6	3.8%	parse ecmascript
494.9	4,611	107.3	46.3	2.0%	compute async chunks
303.3	1,936	156.7	22.1	1.2%	generate source map
71.2	1,858	38.3	14.6	0.3%	collect mergeable modules
68.5	671	102.0	20.5	0.3%	compute binding usage info
60.4	109	553.8	16.7	0.2%	make production chunks
59.7	2,165	27.6	0.2	0.2%	read file
33.8	4	8456.4	16.2	0.1%	compute merged modules
33.5	14	2392.4	9.9	0.1%	apply effects
32.8	13	2523.0	9.9	0.1%	write file
28.6	585	48.8	2.9	0.1%	async reference

---

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 63.3% suggests critical path serialization or lock contention.
• 1,071,921 spans < 10us (67.4%) 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,396.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,251.5 ms	12.9% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,071,921	67.4%
10us - 100us	493,144	31.0%
100us - 1ms	20,980	1.3%
1ms - 10ms	3,912	0.2%
10ms - 100ms	82	0.0%
> 100ms	3	0.0%

---

Diagnostic Signal Summary

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

---

Action Items (P0-P4)

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