Skip to content

feat(pack): support config.react.importSource - #2595

Merged
fireairforce merged 1 commit into
nextfrom
add-complex-loader
Feb 24, 2026
Merged

feat(pack): support config.react.importSource#2595
fireairforce merged 1 commit into
nextfrom
add-complex-loader

Conversation

@fireairforce

Copy link
Copy Markdown
Member

Summary

Test Plan

@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @fireairforce, I'm Gemini Code Assist1! 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 React configuration by enabling support for a custom importSource option. This change streamlines how JSX transformation options are derived, making the configuration more flexible and easier to manage. The updated tests validate that the new configuration is correctly applied and that JSX files are processed as expected.

Highlights

  • React Configuration: Introduced a new import_source field to the ReactConfig struct, allowing custom JSX import sources to be specified in the configuration.
  • JSX Transformation Logic: Refactored the get_jsx_transform_options function to directly utilize the new config.react.import_source and config.react.runtime values, simplifying the logic and removing previous TypeScript configuration checks for jsxImportSource.
  • Test Updates: Updated existing snapshot tests to reflect the new JSX import source handling, including changing the entry file from .js to .jsx and updating expected output and warning snapshots.
Changelog
  • crates/pack-core/src/client/context.rs
    • Updated the call to get_jsx_transform_options by removing the project_path argument.
  • crates/pack-core/src/config.rs
    • Added an import_source field of type Option<RcStr> to the ReactConfig struct.
    • Implemented an as_str method for the ReactRuntime enum to provide string representations of its variants.
  • crates/pack-core/src/transform_options.rs
    • Removed the ReactRuntime import as its as_str method is now directly used.
    • Modified the get_jsx_transform_options function signature to remove the project_path parameter.
    • Updated the JsxTransformOptions construction to prioritize react_config.import_source and react_config.runtime.as_str().
    • Removed the logic that read jsxImportSource from tsconfig files, simplifying the JSX options resolution.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/config.json
    • Changed the entry point in the test configuration from input/index.js to input/index.jsx.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/input/index.js
    • Removed the original JavaScript entry file.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/input/index.jsx
    • Added a new JSX file containing a React component and an import for foreign-jsx-transform.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/issues/Export-default-doesn-t-exist-in-target-module-421f54.txt
    • Added a new snapshot file capturing an expected warning related to a missing default export in the react module.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project___e660a1cd.js
    • Added a new generated JavaScript output file reflecting the updated JSX transformation.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project___e660a1cd.js.map
    • Added a new generated source map file corresponding to the updated JavaScript output.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project__basic_foreign_jsx_transform_9ec7bd5f.js
    • Removed an outdated generated JavaScript output file.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/_project__basic_foreign_jsx_transform_9ec7bd5f.js.map
    • Removed an outdated generated source map file.
  • crates/pack-tests/tests/snapshot/basic/foreign_jsx_transform/output/main.js
    • Updated the otherChunks and runtimeModuleIds to reference the newly generated output files.
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 gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for config.react.importSource to configure the JSX import source. The implementation centralizes this configuration within the bundler's settings, which is a positive step. It also refactors how config.react.runtime is handled, providing a sensible default. However, this PR also removes the existing support for reading compilerOptions.jsxImportSource from tsconfig.json, which is a breaking change that should be documented for users. The code changes are otherwise clean and improve the configuration handling for React's JSX transform.

Comment thread crates/pack-core/src/transform_options.rs
Comment thread crates/pack-core/src/transform_options.rs Outdated
@fireairforce
fireairforce merged commit d2f8589 into next Feb 24, 2026
16 checks passed
@fireairforce
fireairforce deleted the add-complex-loader branch February 24, 2026 02:20
@github-actions

Copy link
Copy Markdown

📊 Performance Benchmark Report (with-antd)

Utoopack Performance Report

Report ID: utoopack_performance_report_20260224_023055
Generated: 2026-02-24 02:30:55
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,869.3 ms Baseline
Total Thread Work (de-duped) 24,729.9 ms Non-overlapping busy time
Effective Parallelism 3.1x thread_work / wall_time
Working Threads 5 Threads with actual spans
Thread Utilization 62.9% 🆗 Average
Total Spans 1,589,426 All B/E + X events
Meaningful Spans (>= 10us) 503,710 (31.7% of total)
Tracing Noise (< 10us) 1,085,716 (68.3% 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,136 3,446.5 13.9%
P3: Asset Pipeline 28,723 3,175.9 12.8%
P4: Bridge/Interop 0 0.0 0.0%
Other 436,851 20,989.4 84.9%

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,729.9 ms
Avg Work per Thread 4,946.0 ms
Effective Parallelism 3.14x
Thread Utilization 62.9%

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,918.4 181,116 43.7 14.3 32.0% module
3,844.0 68,712 55.9 181.6 15.5% process module
3,377.4 35,265 95.8 181.5 13.7% analyze ecmascript module
2,802.2 24,147 116.0 62.6 11.3% code generation
1,755.5 61,062 28.7 9.3 7.1% internal resolving
1,753.2 57,056 30.7 14.3 7.1% resolving
1,342.9 28,378 47.3 32.2 5.4% precompute code generation
1,318.5 13,925 94.7 48.4 5.3% chunking
1,255.9 13,278 94.6 114.7 5.1% compute async module info
983.9 8,035 122.5 82.5 4.0% parse ecmascript
522.1 4,718 110.7 52.6 2.1% compute async chunks
276.2 1,936 142.7 17.5 1.1% generate source map
66.7 587 113.7 18.0 0.3% compute binding usage info
64.1 1,861 34.4 10.5 0.3% collect mergeable modules
59.6 103 578.7 19.2 0.2% make production chunks
59.5 2,165 27.5 0.3 0.2% read file
41.6 533 78.0 5.9 0.2% async reference
37.3 14 2664.0 9.2 0.2% apply effects
36.6 13 2817.1 9.2 0.1% write file
28.2 9 3129.9 13.2 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.9% suggests critical path serialization or lock contention.
  • 1,085,716 spans < 10us (68.3%) 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,446.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,175.9 ms 12.8% of work
Bridge Overhead (P4) 0.0 ms ✅ Low

Duration Distribution

Range Count Percentage
< 10us (noise) 1,085,716 68.3%
10us - 100us 478,968 30.1%
100us - 1ms 20,780 1.3%
1ms - 10ms 3,879 0.2%
10ms - 100ms 80 0.0%
> 100ms 3 0.0%

Diagnostic Signal Summary

Signal Status Finding
Tracing Noise (P0) ⚠️ Significant 68.3% of spans < 10us
Thread Utilization (P0) 🆗 Average 62.9% utilization
Heavy Monoliths (P1) ✅ Minimal 3 tasks > 100ms
Asset Pipeline (P3) Review 3,175.9 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-24
Following: Utoopack Performance Analysis Agent Protocol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants