feat(pack): support styles.postcss

[fireairforce]

Summary

upstream: utooland/next.js#124

Support styles.postcss to pass inline postcss config to turbopack than create a postcss.config.js file under framework case:

import { defineConfig } from "@utoo/pack";

export default defineConfig({
   styles: {
    postcss: {
      plugins: [
        [
          "postcss-plugin-px2rem",
          {
            rootValue: 16,
            unitPrecision: 5,
            replace: true,
            mediaQuery: false,
            minPixelValue: 0,
          },
        ],
      ],
    },
  },
})

Test Plan

add a example to show the case.

[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 enhances the utoo/pack build system by providing a more integrated way to manage PostCSS configurations. It allows developers to specify PostCSS plugins and their options directly within the main configuration file, simplifying project setup and reducing file overhead. This change improves the developer experience by centralizing styling configurations and is accompanied by a practical example to guide implementation.

Highlights

• Inline PostCSS Configuration: Introduced support for defining PostCSS plugins directly within the styles.postcss section of the utoo/pack configuration, eliminating the need for a separate postcss.config.js file.
• New Example Project: Added a new example, examples/with-postcss, to demonstrate the usage of inline PostCSS configuration with postcss-plugin-px2rem.
• Configuration Schema Updates: Updated the core configuration schema and shared types to include the new postcss option under styles and removed several deprecated experimental features.

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.

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 support for inline PostCSS configuration, allowing users to define PostCSS plugins directly within their utoopack.config.mjs file. This was implemented by adding a postcss field to the StyleConfig and SchemaStyleConfig structures, and integrating logic in both client and server contexts to serialize and apply this configuration. A new example, examples/with-postcss, was added to demonstrate this feature, showcasing how postcss-plugin-px2rem can be used inline. The review noted that the logic for retrieving and serializing the inline PostCSS configuration is duplicated in both client and server contexts, suggesting it should be extracted into a shared helper function to improve maintainability.

[xusd320]

config_str 语意上是不是更清晰些？

[fireairforce]

ok，inline_config 容易跟 inline_style 这种搞混

[fireairforce]

config_content 吧

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260318_083704
Generated: 2026-03-18 08:37:04
Trace File: trace_antd.json (0.6GB, 1.74M spans)
Test Project: examples/with-antd

---

Executive Summary

Metric	Value	Assessment
Total Wall Time	15,759.5 ms	Baseline
Total Thread Work (de-duped)	53,831.9 ms	Non-overlapping busy time
Effective Parallelism	3.4x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	68.3%	🆗 Average
Total Spans	1,738,405	All B/E + X events
Meaningful Spans (>= 10us)	676,636	(38.9% of total)
Tracing Noise (< 10us)	1,061,769	(61.1% 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	151,087	8,674.1	7,065.6	11,015.6
Parse	12,598	2,828.7	2,499.0	15,561.8
Analyze	392,618	38,761.5	29,738.0	14,947.5
Chunk	31,597	3,720.1	3,515.6	12,038.8
Codegen	75,279	5,732.9	4,298.0	12,126.0
Emit	75	79.5	41.0	12,155.9
Other	13,382	2,679.2	2,207.9	15,759.5

---

Workload Distribution by Diagnostic Tier

Category	Spans	Inclusive (ms)	% Work	Self-Time (ms)	% Self
P0: Scheduling & Resolution	553,313	49,377.2	91.7%	38,296.8	71.1%
P1: I/O & Heavy Tasks	3,320	210.9	0.4%	172.4	0.3%
P2: Architecture (Locks/Memory)	0	0.0	0.0%	0.0	0.0%
P3: Asset Pipeline	118,279	12,295.4	22.8%	10,326.3	19.2%
P4: Bridge/Interop	0	0.0	0.0%	0.0	0.0%
Other	1,724	592.6	1.1%	569.5	1.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
19,527.5	22,144.1	245,709	79.5	0.1	56.7	36.3%	module	write all entrypoints to disk (1%)
5,130.6	6,870.2	41,200	124.5	0.2	236.2	9.5%	analyze ecmascript module	process module (72%)
3,680.6	3,911.2	70,242	52.4	0.1	30.8	6.8%	internal resolving	resolving (29%)
3,370.5	4,748.5	80,132	42.1	0.0	21.2	6.3%	resolving	module (35%)
3,358.1	7,989.3	83,104	40.4	0.1	27.9	6.2%	process module	module (17%)
2,504.2	2,674.6	17,391	144.0	0.3	155.1	4.7%	chunking	write all entrypoints to disk (0%)
2,126.3	3,561.2	28,083	75.7	0.2	60.8	3.9%	code generation	chunking (7%)
2,081.8	2,191.5	9,185	226.7	0.7	78.6	3.9%	parse ecmascript	analyze ecmascript module (28%)
1,818.5	1,818.5	45,116	40.3	0.1	8.0	3.4%	precompute code generation	code generation (26%)
1,579.2	2,020.7	10,641	148.4	0.0	425.2	2.9%	write all entrypoints to disk	None (0%)
1,500.3	1,500.3	19,211	78.1	0.3	180.3	2.8%	compute async module info	chunking (0%)
966.7	967.3	14,017	69.0	0.1	84.3	1.8%	compute async chunks	compute async chunks (0%)
518.6	532.6	1,477	351.1	1.5	37.4	1.0%	webpack loader	parse css (12%)
353.2	353.2	2,080	169.8	0.5	18.1	0.7%	generate source map	code generation (96%)
300.2	520.2	881	340.7	0.8	31.3	0.6%	parse css	module (6%)
130.7	130.7	1,337	97.8	0.0	42.1	0.2%	compute binding usage info	write all entrypoints to disk (0%)
116.7	116.7	2,509	46.5	0.1	8.5	0.2%	read file	parse ecmascript (85%)
67.2	67.2	2,026	33.2	0.0	12.2	0.1%	collect mergeable modules	compute merged modules (0%)
59.2	65.9	1,017	58.2	0.1	6.5	0.1%	async reference	write all entrypoints to disk (1%)
44.6	78.1	189	236.2	0.4	31.2	0.1%	make production chunks	chunking (3%)

---

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	236.3	2	process module → analyze ecmascript module
2	89.0	2	process module → analyze ecmascript module
3	81.3	2	process module → analyze ecmascript module
4	79.7	2	process module → analyze ecmascript module
5	78.9	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	41,200	process module (72%)	124.5 us	0.21 ms	5,130.6 ms

---

Duration Distribution

Range	Count	Percentage
<10us	1,061,769	61.1%
10us-100us	638,101	36.7%
100us-1ms	29,763	1.7%
1ms-10ms	8,038	0.5%
10ms-100ms	724	0.0%
>100ms	10	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