chore(deps): update swc-next to v0.2.3

[SoonIter]

Motivation

Update the formatter to SWC Next v0.2.3 to include the latest parser fixes and decoder improvements.

Changes

Upgrade @swc-next/parser from 0.2.2 to 0.2.3 and refresh the lockfile for its decoder and all native platform bindings.

Validated with builds, pnpm check, all 393 tests, and formatting runs on fixed Rsbuild and Rspack source snapshots. Repeated end-to-end benchmarks show no clear performance change; detailed results are provided in a PR comment.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-28T08:14:54.728394Z	0eab404	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[cloudflare-workers-and-pages]

Deploying rstack-cli with    Cloudflare Pages

Latest commit:	0eab404
Status:	✅  Deploy successful!
Preview URL:	https://764d2957.rstack-cli.pages.dev
Branch Preview URL:	https://soon-codex-swc-next-0-2-3.rstack-cli.pages.dev

View logs

[SoonIter]

Formatter benchmark: SWC Next 0.2.2 vs 0.2.3

The repeated fmt --write benchmark shows no clear end-to-end performance change on either repository. Both paired 95% bootstrap intervals include zero.

Repository	Files	0.2.2 median	0.2.3 median	Median paired time change	Paired 95% interval	Faster rounds
Rsbuild	3,349	1.419 s	1.404 s	-1.2%	[-1.8%, +0.9%]	13/20
Rspack	4,683	2.721 s	2.715 s	-0.8%	[-2.5%, +1.8%]	13/20

Negative changes mean lower elapsed time. The paired statistic is the median of same-round percentage changes, not the percentage difference between the two marginal medians.

Method

• Apple M5 Max, 64 GiB, macOS ARM64; Node 24.20.0; Prettier 3.9.9.
• Per version/repository: 3 warmups and 20 measured runs, balanced randomized order, fresh Node processes, 8 workers, warm filesystem caches.
• NODE_DISABLE_COMPILE_CACHE=1 node <variant>/bin/rs.js fmt --write --no-cache --parallel-workers 8.
• Byte-identical built CLI JavaScript and the same release-profile rstack native helper; only the SWC Next parser/decoder/native parser packages differ.
• Fixed source snapshots: Rsbuild f69eb5a6 and Rspack aad04d06, retaining repository formatter settings, plugins, and ignore rules.
• Timings cover the full CLI process, including startup, discovery, formatting, and shutdown. The corpus was already formatted, so timed write-mode runs reported no changes; this does not measure rewriting every file to disk.

Runtime and output verification

Separate untimed traces confirmed that all eight workers actually called the intended parser version. Parser, decoder, and loaded native parser binaries were 0.2.2 for the baseline and 0.2.3 for the upgrade, with different hashes. The installed 0.2.3 native parser exactly matches the release workflow artifact; its parser/decoder JavaScript matches release commit 50a04f05.

All 92 write-mode benchmark invocations passed. Before/after hashes of all tracked source files confirmed identical output across versions. Additional checks introduced a formatting difference in one TypeScript file per repository; both versions formatted that file and restored the original bytes.

Earlier check-mode measurements

The first batch used the same cache/worker controls and 3 warmups + 20 measured runs, with --check instead of --write.

Repository	0.2.2 median	0.2.3 median	Median paired time change	Paired 95% interval	Faster rounds
Rsbuild	1.498 s	1.529 s	+0.3%	[-2.7%, +3.9%]	9/20
Rspack	2.946 s	2.848 s	-4.3%	[-6.2%, -1.2%]	16/20

The apparent Rspack improvement did not reproduce in the write-mode rerun, so it should not be treated as a stable benefit. Since the mode also changed, these batches do not isolate the cause of the difference.

Validation also passed: builds, pnpm check, 393 tests, and a frozen-lockfile install.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved review issues were identified.

Review effort: Lite
Findings: None

What changed in this PR

Updates SWC Next parser from v0.2.2 to v0.2.3 for parser fixes and decoder improvements.

Changes:

• Bumps the shared parser catalog version.
• Refreshes lockfile entries and native platform bindings.

File	Description
pnpm-workspace.yaml	Updates @swc-next/parser to 0.2.3.
pnpm-lock.yaml	Refreshes parser, decoder, and native binding entries.

Files not reviewed (1)

• pnpm-lock.yaml: Generated file

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[SoonIter]

Follow-up: interpreting the JS encoding and native-call timings

The shorter native-call time in 0.2.3 does not directly measure an equivalent improvement in the Rust parser: the timing boundary changed.

• 0.2.2: the binding accepts a Rust String. Converting the JavaScript string to UTF-8 happens inside the timed NAPI call.
• 0.2.3: the JS wrapper allocates a Uint8Array(source.length * 3), encodes with TextEncoder.encodeInto, and shrinks/transfers the buffer to the written length. The native binding then borrows the UTF-8 bytes. This encoding and buffer handling happens outside the timed native call.

SWC Next #725 introduced this approach so the native parser and decoder can reuse source bytes, alongside other bridge/decoding changes. It should not be described as simply adding a second encoding pass.

For example, the JS/TS-only Rsbuild profile produced these median aggregate spans across three instrumented runs per version:

Stage	0.2.2	0.2.3
Native call	44.5 ms, including string conversion	33.4 ms
Explicit JS encoding and buffer handling	Included in the native boundary	14.0 ms
Complete public parseSync call	63.4 ms	66.9 ms

These are accumulated elapsed spans across workers, not whole-command wall times or pure CPU measurements. Public parseSync includes initial lazy-decoder setup; subsequent AST materialization is measured separately. Instrumentation also affects small spans.

The supported conclusion is that the native call gets shorter, but including the work moved into JS leaves no clear public-parser benefit on this small-file workload. Separate JS-only, TS-only, and combined JS/TS CLI benchmarks—3 warmups and 20 measured runs per version/group/repository—also found no clear end-to-end change on either Rsbuild or Rspack; all paired 95% intervals crossed zero.

This does not establish that the encoding strategy itself caused a regression. Isolating that effect requires an A/B test that holds the other parser and decoder changes constant and switches only the encoding path.

[SoonIter]

JS-only, TS-only, and combined JS/TS formatter benchmarks

I also tested JavaScript and TypeScript separately, excluding Markdown, MDX, TOML, JSON, CSS, and other formats.

Each repository/group/version used 8 workers, disabled formatter and Node compile caches, 3 warmups, and 20 measured runs in balanced randomized order.

Repository	Group	Files	0.2.2 median	0.2.3 median	Median paired time change	Paired bootstrap 95% interval
Rsbuild	JS	827	263.6 ms	266.0 ms	+0.1%	[-1.0%, +1.7%]
Rsbuild	TS	1,476	583.3 ms	584.4 ms	+0.8%	[-2.9%, +3.1%]
Rsbuild	JS+TS	2,303	672.3 ms	681.3 ms	+0.9%	[-1.1%, +2.9%]
Rspack	JS	652	336.6 ms	330.5 ms	-0.4%	[-1.4%, +2.4%]
Rspack	TS	3,119	861.7 ms	856.6 ms	-0.3%	[-1.3%, +1.4%]
Rspack	JS+TS	3,771	999.2 ms	994.3 ms	+1.4%	[-1.1%, +3.6%]

No clear performance change was detected in any group: all six paired intervals include zero. Negative changes mean lower elapsed time. The paired statistic is the median of same-round percentage changes, not the percentage difference between the two marginal medians.

Method

• Apple M5 Max, 64 GiB, macOS ARM64; Node 24.20.0; Prettier 3.9.9.
• Fixed snapshots: Rsbuild f69eb5a6 and Rspack aad04d06.
• Explicit file lists selected from the verified formatter corpus, retaining repository formatting settings and ignore rules. JS includes js/jsx/mjs/cjs; TS includes ts/tsx/mts/cts, including declaration files. JS+TS is their union.
• Fresh Node processes and warm filesystem caches; byte-identical built CLI JavaScript and the same release-profile rstack native helper. Runtime checks confirmed the intended SWC Next parser, decoder, and native binding versions.
• Command: NODE_DISABLE_COMPILE_CACHE=1 NO_COLOR=1 node <variant>/bin/rs.js fmt --write --no-cache --parallel-workers 8 <explicit files...>.
• All 276 invocations passed with the expected file counts and no changes. Inputs were already formatted, so this measures formatting/comparison in write mode, not rewriting every file to disk.
• Timings include process/worker startup, configuration, file handling, formatting, and shutdown. Because explicit file lists replace whole-repository discovery, subtracting these timings from the earlier whole-repository results would not isolate the cost of non-JS/TS files.

Separate profiling of the combined JS/TS groups found that SWC public parsing plus AST materialization/adaptation accounted for roughly 9% of accumulated per-file elapsed time, while the remaining Prettier span accounted for roughly 80%. These are overlapping-worker aggregate spans, not wall-clock fractions or pure printer CPU time. Excluding document formats alone therefore does not make parser improvements dominate the CLI result.