chore: add napi types for config.react

[fireairforce]

Summary

Test Plan

[gemini-code-assist]

Summary of Changes

Hello @fireairforce, 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 refactors the handling of React runtime configuration by introducing a dedicated ReactRuntime enum in the core Rust configuration. This change enhances type safety and clarity for the runtime option within ReactConfig. It also updates the JSX transformation logic to correctly process these new enum values and extends the shared TypeScript configuration to reflect these changes, ensuring a consistent and type-safe configuration experience.

Highlights

• Type Safety for React Runtime: Introduced a new ReactRuntime enum in Rust to strongly type the runtime option within ReactConfig, replacing a generic string type for improved type safety and clarity.
• JSX Transformation Logic Update: Updated the get_jsx_transform_options function to correctly interpret and map the new ReactRuntime enum values to their corresponding string representations ('automatic' or 'classic') for JSX transformation.
• Shared Configuration Interface Enhancement: Extended the shared TypeScript configuration interface (ConfigComplete) to include the react.runtime property with specific string literal types, ensuring consistency and type safety across the project's configuration.

Changelog

• crates/pack-core/src/config.rs
  • Defined a new ReactRuntime enum with Automatic and Classic variants.
  • Modified the ReactConfig struct to use Option<ReactRuntime> for its runtime field instead of Option<RcStr>.
• crates/pack-core/src/transform_options.rs
  • Imported the newly defined ReactRuntime enum.
  • Adjusted the get_jsx_transform_options function to map ReactRuntime enum values to their string equivalents ('automatic' or 'classic') for the runtime field.
• packages/pack-shared/src/config.ts
  • Added an optional react object with a runtime property ('automatic' | 'classic') to the ConfigComplete TypeScript interface.

Activity

• No activity has been recorded yet 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 refactors the React JSX runtime configuration to use a dedicated ReactRuntime enum instead of a generic string. This is a great improvement for type safety and code clarity. The changes are applied consistently across the Rust backend and the TypeScript configuration types. I have one minor suggestion to make the implementation slightly more idiomatic.

[github-actions]

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260212_040115
Generated: 2026-02-12 04:01:15
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,037.4 ms	Baseline
Total Thread Work (de-duped)	24,977.1 ms	Non-overlapping busy time
Effective Parallelism	3.1x	thread_work / wall_time
Working Threads	5	Threads with actual spans
Thread Utilization	62.2%	🆗 Average
Total Spans	1,589,050	All B/E + X events
Meaningful Spans (>= 10us)	513,160	(32.3% of total)
Tracing Noise (< 10us)	1,075,890	(67.7% 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,347	3,538.5	14.2%
P3: Asset Pipeline	28,767	3,413.2	13.7%
P4: Bridge/Interop	0	0.0	0.0%
Other	446,046	21,112.2	84.5%

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)	24,977.1 ms
Avg Work per Thread	4,995.4 ms
Effective Parallelism	3.11x
Thread Utilization	62.2%

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
7,845.4	184,028	42.6	9.6	31.4%	module
4,027.9	69,795	57.7	152.0	16.1%	process module
3,457.4	35,467	97.5	151.9	13.8%	analyze ecmascript module
2,748.8	24,556	111.9	62.2	11.0%	code generation
1,793.4	62,334	28.8	13.0	7.2%	internal resolving
1,751.6	58,086	30.2	6.5	7.0%	resolving
1,460.0	14,033	104.0	50.1	5.8%	chunking
1,343.9	30,428	44.2	10.0	5.4%	precompute code generation
1,243.7	13,616	91.3	130.8	5.0%	compute async module info
1,047.3	8,053	130.0	88.4	4.2%	parse ecmascript
517.1	4,650	111.2	50.1	2.1%	compute async chunks
303.8	1,936	156.9	23.5	1.2%	generate source map
81.0	1,861	43.5	18.3	0.3%	collect mergeable modules
75.7	666	113.7	24.4	0.3%	compute binding usage info
69.2	2,168	31.9	9.2	0.3%	read file
68.2	89	766.0	19.9	0.3%	make production chunks
50.8	557	91.3	8.1	0.2%	async reference
40.0	5	7991.9	19.9	0.2%	compute merged modules
35.2	14	2514.5	13.8	0.1%	apply effects
31.9	13	2452.8	13.7	0.1%	write file

---

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.2% suggests critical path serialization or lock contention.
• 1,075,890 spans < 10us (67.7%) 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,538.5 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,413.2 ms	13.7% of work
Bridge Overhead (P4)	0.0 ms	✅ Low

---

Duration Distribution

Range	Count	Percentage
< 10us (noise)	1,075,890	67.7%
10us - 100us	488,132	30.7%
100us - 1ms	21,040	1.3%
1ms - 10ms	3,906	0.2%
10ms - 100ms	79	0.0%
> 100ms	3	0.0%

---

Diagnostic Signal Summary

Signal	Status	Finding
Tracing Noise (P0)	⚠️ Significant	67.7% of spans < 10us
Thread Utilization (P0)	🆗 Average	62.2% utilization
Heavy Monoliths (P1)	✅ Minimal	3 tasks > 100ms
Asset Pipeline (P3)	Review	3,413.2 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