refactor(javascript): migrate parser to SWC Next - #15331
Conversation
d87ae01 to
0e5aafe
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e5aafe25f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
0e5aafe to
ebe5ec8
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ebe5ec8a3f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
4af7d71 to
65f5e0e
Compare
📦 Binary Size-limit
🎉 Size decreased by 856.00KB from 68.30MB to 67.47MB (⬇️1.22%) |
Rsdoctor Bundle Diff Analysis
Found 5 projects in monorepo, 5 projects with changes. 📊 Quick Summary
📋 Detailed Reports (Click to expand)📁 popular-libsPath:
📦 Download Diff Report: popular-libs Bundle Diff 📁 react-1kPath:
📦 Download Diff Report: react-1k Bundle Diff 📁 ui-componentsPath:
📦 Download Diff Report: ui-components Bundle Diff 📁 react-5kPath:
📦 Download Diff Report: react-5k Bundle Diff 📁 react-10kPath:
📦 Download Diff Report: react-10k Bundle Diff 🤖 AI Degradation Analysis (Click to expand)📁 popular-libs📊 Size ChangesNo significant regressions detected 🎉. Total bundle size decreased slightly from 1,821,866 bytes to 1,821,840 bytes (-26 bytes). Initial JS chunk remains stable at ~1.82 MB. 🔍 Root Cause Analysis
|
| Asset / Chunk | Baseline | Current | Δ Size | Δ % | Initial? |
|---|---|---|---|---|---|
| No significant regressions detected 🎉 | - | - | - | - | - |
🔍 Root Cause Analysis
- Total bundle size decreased by 26 bytes (0.003%).
react-routerv7.18.2 parsed size reduced slightly (35,481 → 35,455 bytes).- No new modules or dependencies added.
⚠️ Risk Assessment
Overall severity: Low
- Initial chunk size decreased (776,474 → 776,448 bytes), ensuring no negative impact on FCP or total load time.
💡 Optimization Suggestions
- No action required; this PR is performance-neutral.
- Continue monitoring
react-routerupdates for potential tree-shaking improvements in future versions.
Analysis by qwen3.5-plus
📁 ui-components
📊 Size Changes
No significant regressions detected 🎉.
🔍 Root Cause Analysis
- Total Bundle: Decreased by 682 bytes (5,138,933 → 5,138,251).
@vueuse/core: Parsed size reduced 3,132 → 3,035 bytes (-3.1%).@zag-js/select: Parsed size reduced 21,065 → 20,936 bytes.- Initial JS: Decreased 5,023,373 → 5,022,691 bytes.
⚠️ Risk Assessment
Overall severity: Low
- Initial chunk size decreased slightly; no negative impact on load performance or regressions >5%.
💡 Optimization Suggestions
- Maintain current tree-shaking configuration for
@vueuse/coreto preserve gains. - Monitor
@rc-component/motion(parsed size +7 bytes) if updated in future releases. - No immediate action required; safe to merge.
Analysis by qwen3.5-plus
📁 react-5k
📊 Size Changes
No meaningful change detected. Total bundle size decreased negligibly by 26 bytes (2.79 MB → 2.79 MB). No regressions >5% or >10 KB found 🎉.
🔍 Root Cause Analysis
- Minor variance in
react-routerparsed size (35,481 → 35,455 bytes) due to build hashing or internal patching. - No new modules or duplicate dependencies introduced.
⚠️ Risk Assessment
Overall severity: Low
- Initial chunk size decreased by 26 bytes; zero impact on Time to Interactive or load performance.
💡 Optimization Suggestions
- No action required; bundle health is stable.
- Continue monitoring
react-routerupdates for potential major version upgrades if further optimization is needed.
Analysis by qwen3.5-plus
📁 react-10k
📊 Size Changes
No significant regressions detected 🎉.
Win: Total JS bundle decreased slightly (5,860,720 → 5,860,694 bytes; -26 bytes). Initial JS also decreased (746,165 → 746,139 bytes).
🔍 Root Cause Analysis
- Minor reduction driven by
react-routerparsed size change (35,481 → 35,455 bytes). - No new modules, dependencies, or duplicates introduced.
⚠️ Risk Assessment
Overall severity: Low
- Total bundle size delta is negligible (-26 bytes); no impact on initial load performance or user experience.
💡 Optimization Suggestions
- Safe to merge: No performance degradation detected.
- Monitor: Keep an eye on
react-routerupdates to ensure continued tree-shaking efficiency. - Maintain: Current bundling configuration is stable; no immediate code-splitting actions required.
Analysis by qwen3.5-plus
Generated by Rsdoctor GitHub Action
Merging this PR will improve performance by 11.18%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Simulation | rust@scan_dependencies@three_module |
12.9 ms | 9.3 ms | +38.61% |
| ⚡ | Simulation | bundle@threejs-production-sourcemap |
191.4 ms | 174.4 ms | +9.74% |
| ⚡ | Simulation | bundle@threejs-development |
123.7 ms | 113.1 ms | +9.45% |
| ⚡ | Simulation | bundle@basic-react-development |
151.7 ms | 141.7 ms | +7.01% |
| ⚡ | Simulation | bundle@misc-production-sourcemap |
3.6 s | 3.4 s | +5.8% |
| ⚡ | Simulation | bundle@misc-development |
2.8 s | 2.6 s | +5.61% |
| ⚡ | Simulation | bundle@basic-react-production-sourcemap |
136.2 ms | 129.1 ms | +5.49% |
Tip
Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.
Comparing seal/swc-next-parser-migration (6f58f90) with main (a338733)
Footnotes
-
47 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
b59f259 to
749e39b
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
📝 Benchmark detail: Open
Base persistent cache hit rate: 👍 Current persistent cache hit rate: 👍 |
696f5b8 to
cf3db7b
Compare
Deploying rspack with
|
| Latest commit: |
cf3db7b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d4411bed.rspack-v2.pages.dev |
| Branch Preview URL: | https://seal-swc-next-parser-migrati.rspack-v2.pages.dev |
|
@codspeedbot explain why rust@scan_dependencies is faster |
I profiled this benchmark specifically (head First, the important scoping detail: this benchmark cannot be measuring the parser swap. In The bench is also very low-noise — two consecutive Where the −3.0 ms sits
The entire delta is in the main walk; the pre-walk phases and the location advancer ( What actually got cheaper in the walk
The win came from the follow-up commits, not the migration itselfSame benchmark, along the branch:
The raw port to the SWC Next AST made the walker slower; the −23% is entirely the semantic-reuse / dense-state / borrowed-pattern work layered on top. Two caveats
If you want more from this path, the clearest remaining item is No code changes were needed — this is an analysis-only answer. Summary
Learnings updated. See what CodSpeed remembers about this repository. Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot. |
|
@codspeedbot explain why bundle@threejs-production-sourcemap is faster |
I re-profiled this benchmark on the current head (
1. Module build: −10.8 msAll of it is inside
Three things to note:
Net: on a cold build the walker's −4.8 ms roughly cancels the analyzer's +5.6 ms, so the module-build win is essentially the parser and the removed fixup passes. 2. Scope hoisting: −5.4 msThis case is production + scope hoisting, so every module is parsed a second time, and that parse gets the same win:
Only −5.4 of that −9.6 survives, because identifier handling costs more: −10.8 and −5.4 account for −16.2 of the −16.7 ms. Where the remaining headroom is
One caveat: base and head ran on different runner CPUs (EPYC 7763 → 9V74), which is worth ~2% on Simulation — not material at a +9.55% delta, but worth knowing. No code changes were needed; this is an analysis-only answer. Summary
Learnings updated. See what CodSpeed remembers about this repository. Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot. |
Summary
swc_experimental_*JavaScript analysis parser, AST, semantic model, walkers, evaluator, and parser plugins directly with SWC Next without introducing a compatibility crate or runtime backend switch0.1.3crates from crates.io; all direct and transitiveswc_next_*packages are registry dependencies pinned byCargo.lockchecksumsmainparser behavior, including dynamic imports inPromise.alldestructuring, while updating parse-error diagnostic expectations for SWC Next wording and renderingValidation:
maincommitc1ca9e2c323d9cdec8d510dfba4d15d081955737cargo clippy --workspace --all-targets --tests --locked -- -D warningscargo deny --all-features check license banscargo xtask deny-extcargo test -p rspack_plugin_javascript --lib --locked(48 passed)cargo fmt --all -- --checkpnpm run build:binding:devpnpm run lint:jspnpm run test:unit(Rspack core: 9135 passed, 4 existing skipped; CLI: 89 passed, 1 existing skipped; node binding type test passed)Known upstream limitation:
swc_next_ecma_ast 0.1.3unconditionally rejects big-endian targets in its AST FFI, so the s390x build case is temporarily skipped until upstream supports that target; no JavaScript correctness cases are skippedChecklist