Update `estree-conformance` submodule to latest.
On latest commit, TS-ESLint parser dependency has been bumped including a bug fix for tokens (https://github.com/typescript-eslint/typescript-eslint/pull/12821).
We already made the corresponding fix in `oxc_parser` in #26328. Now we can remove the workaround to skip 2 conformance test cases where TS-ESLint previously produced the wrong tokens.
## Summary
- Wait for N-API platform packages to expose metadata and downloadable tarballs before publishing their parent package
- Poll npm with exact-version metadata requests and ranged tarball requests
- Apply the ordering guard to Oxlint, Oxfmt, and reusable N-API releases
- Run affected publish jobs on `ubuntu-latest` instead of the 15-minute `ubuntu-slim` runner
## Testing
- `node --check .github/scripts/wait-for-npm-packages.mjs`
- `oxfmt --check` on the changed script and workflows
- Targeted Oxlint check on the new script
- Live registry checks for six already-published scoped and unscoped packages
- GitHub Actions PR title and Lint checks pass
Update the coverage harness and fixture consumers for TypeScript's merged `tsc/testdata` layout, including separate compiler and conformance baseline directories. Handle strict/checkJs baseline variants and exclude fixtures without any reference baseline. Update fixture revisions, conformance snapshots, and the existing NAPI token-test exclusion paths. Remove the temporary snapshot path translation from the parent PR.
Local conformance reproduced the updated snapshots, and all 237,025 parser NAPI tests passed with token, range/parent, and lazy-transfer modes enabled. The snapshots retain the false failures for the two TS2339 fixtures without special-case exclusions.
Remove the Prettier related stuff from the conformance, which is purely aimed at JS/TS.
Instead, `oxc_formatter_tests` manage Prettier's test fixtures along with Oxfmt.
Adds CodSpeed's [Memory Instrument](https://codspeed.io/docs/instruments/memory) for the `pipeline` benchmarks: peak memory, total allocated bytes, allocation count, and a memory timeline per benchmark case, tracked with baseline comparison on PRs alongside the existing CPU simulation runs.
## Changes
- `generate-benchmark-matrix.js`: entry construction is factored into a `buildMatrixEntries()` helper used by all five construction sites. All entries now carry an explicit `mode`: `simulation` for every component, `simulation,memory` for `pipeline` — so the pipeline job runs both instruments and inherits the existing changed-file affection logic.
- `benchmark.yml`: the action's `mode:` input comes from the matrix. Job names and count are unchanged.
No build-step changes needed: `cargo-codspeed` maps memory mode to the same `analysis` build the workflow already stages (`MeasurementMode::Memory` → `BuildMode::Analysis`), and the pinned action v4.18.5 supports memory mode (added in v4.17.0) including comma-separated multi-mode runs.
Notes:
- The first memory numbers on this PR will have no baseline; comparisons start after the post-merge main run.
- Memory metrics reflect the bench crate's deliberate `NeverGrowInPlaceAllocator` worst-case realloc behavior — consistent run-to-run, which is what matters for regression tracking.
AI Disclosure: This was generated with Claude Code, Fable 5. It has been tested and reviewed by me for correctness.
### Summary
The include-mode filter in `check-changes.js` short-circuits to "skip" when no changed files are under `crates/`, so it never reaches the cargo tree dependency check for `Cargo.lock`-only dependency updates or `rust-toolchain.toml` bumps. Conformance, Minsize, Allocations, and Linter timings are all gated on this filter.
This is how #24192 (`num-bigint` 0.4.6 → 0.5.1) landed with a stale parser allocation snapshot: the update changed BigInt-literal parsing allocation counts, the Allocations job never re-measured on main, and the mismatch surfaced on an unrelated PR (#24098). The snapshot itself is fixed in #24198.
This PR treats `Cargo.lock` and `rust-toolchain.toml` changes as affecting every crate, so measurement jobs always re-run on dependency and toolchain updates. The cost is that renovate dependency PRs now run these four jobs; dependency updates are exactly the class of change that can shift measured behavior, so that is the intended behavior. Exclude-mode and paths-only jobs are unaffected (exclude mode already runs on such changes by construction).
### Trade-off
For Conformance specifically this closes a correctness gap, not just a snapshot-staleness one: a dependency update that changes parser/transformer behavior currently skips conformance entirely.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Closes https://github.com/oxc-project/oxc/issues/10048
Integrates the Rust port of the React Compiler ([facebook/react#36173](https://github.com/facebook/react/pull/36173)) into oxc.
## Notes (resolved)
- Published crates can't reference Git URLs, so using this from Rolldown needs the React Compiler crates on crates.io. ✅ Published as a fork at https://crates.io/crates/forked_react_compiler; this PR depends on those `forked_react_compiler*` crates so people can get earlier access.
- The React Compiler crates had no license field. ✅ The published fork carries `license = "MIT"` (per the React repo's MIT license), so Cargo Deny and Security Analysis pass.
## Benchmark
**Wall-clock overhead vs plain transform** (release `transformSync`, same `jsx: automatic`, toggling only `reactCompiler`):
| fixture | without | with | overhead |
| --- | --- | --- | --- |
| RadixUIAdoptionSection.jsx (2.5 KiB) | 0.03 ms | 1.81 ms | +1.8 ms |
| excalidraw `App.tsx` (406 KiB) | 4.09 ms | 14.49 ms | +10.4 ms (3.5×) |
So roughly a fixed ~1.8 ms floor per file plus a per-size cost — about **3.5× the transform time** on a large real-world component.
## Binary size
Linking the React Compiler pulls the whole compiler pipeline (HIR, lowering, inference, SSA, optimization, reactive scopes, validation) plus the oxc⇄Babel AST conversion into the binding. Release build of the napi transform addon (`transform.darwin-arm64.node`, `--release`, stripped), darwin-arm64:
| build | size |
| --- | --- |
| baseline (`main`) | 3.51 MiB |
| with React Compiler | 8.66 MiB |
| **delta** | **+5.14 MiB (+146%, 2.46×)** |
## Summary
This PR covers the release automation follow-up from #19890.
It replaces the earlier Rust-based prototype with a small Node script,
`.github/scripts/update-rule-versions.js`, that scans
`declare_oxc_lint!` declarations under `crates/oxc_linter/src/rules/**`
and:
- rewrites stable `version = "next"` entries to the actual oxlint
release version during release prep
- leaves `nursery` rules on `version = "next"`
- reuses the same script during release CI and fails if rerunning it
would still rewrite tracked rule files, so no stable `version = "next"`
remains at release time
- prints a simple change report
- supports `--dry-run` for local verification
The implementation also now hardens a few failure modes that came up
during review:
- comment-only lines inside `declare_oxc_lint!` blocks are ignored when
parsing metadata
- trailing `// ...` and single-line `/* ... */` comments on metadata
lines are handled correctly
- multi-line block comments on metadata lines and macro terminators are
handled correctly
- doc examples inside the macro block that mention `version = "next"`
are not misclassified as invalid matches
- symlinked entries under the lint rules tree are rejected instead of
being silently skipped
- the script still fails if `version = "next"` is found outside a
`declare_oxc_lint!` block
Workflow changes:
- `.github/workflows/prepare_release_apps.yml` sets up Node and runs the
rewrite script after `cargo release-oxc update`
- `.github/workflows/release_apps.yml` sets up Node, reruns the script
with the released oxlint version, and then checks `git diff --exit-code
-- crates/oxc_linter/src/rules`
## Testing
```bash
node --test .github/scripts/update-rule-versions.test.js
node .github/scripts/update-rule-versions.js --root . --release-version 1.61.0 --dry-run
cargo check -p oxc_linter --locked
```
## Notes
This PR intentionally does not include the docs/website wiring from
#19890.
That should stay in a follow-up PR since it touches a different data
flow and also involves `oxc-project/website#937`.
## AI Usage Disclosure
I used AI assistance to help inspect the release workflows, compare the
implementation direction against the maintainer feedback, and draft the
initial automation changes. I manually reviewed the final
implementation, added the regression tests for the workflow guard and
parser edge cases above, ran the checks listed here, and remain
responsible for the final code and submission.
---------
Co-authored-by: Cam McHenry <camchenry@users.noreply.github.com>
Co-authored-by: Cameron <cameron.clark@hey.com>
## Summary
- Replace `git clone --depth 1` with `git init` + `git remote add` for
fresh submodule directories, so `git fetch --depth 1 origin <sha>` is
the only network operation
- Remove redundant `remote set-url` that ran after a fresh clone (the
URL was already correct from the clone command)
- Merge the "directory exists but no .git" and "directory doesn't exist"
branches into a single code path
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- Replace bespoke check-conformance-changes.js with the reusable
check-changes action, eliminating 126 lines of duplicated
change-detection logic
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- 4 NAPI jobs (`test-napi-oxlint`, `test-napi-oxfmt`, and their Windows
variants) pass only `--paths` without `--packages` or `--exclude`, which
hit the error fallback in `check-changes.js` and always returned `true`
— causing them to run on every PR regardless of changed files
- Add a paths-only code path that checks changed files against trigger
paths without cargo tree dependency resolution
- Estimated savings: ~145s (oxlint) + ~96s (oxfmt) on PRs; ~741s
(oxlint-windows) + ~476s (oxfmt-windows) on main
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- CI publish workflow fails when re-run after a partial publish because
npm rejects republishing an existing version
- Add version-published checks to `check-npm-packages.js` so
already-published packages are skipped in the dry-run step
- Extract a shared `publish-if-needed.sh` script that checks the npm
registry before publishing, used by all three trusted publish steps
- Consolidate the old `checkPackageExists` and new version check into a
single `npmViewVersion` helper to avoid redundant npm registry calls
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## Summary
- Replace `dorny/paths-filter` in 6 CI jobs with a unified
`check-changes.js` script that uses `cargo tree` to resolve transitive
dependencies, fixing silent CI skips when upstream crates change
- Add a reusable `check-changes` composite action to eliminate
boilerplate across jobs
- Add change detection to Miri workflow to skip expensive steps when
unrelated code changes
### Key improvements over old `dorny/paths-filter`
- **Transitive dependency tracking**: uses `cargo tree` so e.g.
`oxc_parser` changes correctly trigger minification checks
- **Task crate resolution**: uses actual task crates (`oxc_minsize`,
`oxc_track_memory_allocations`) instead of library crates, catching
dev-dependencies like `oxc_codegen` that `cargo tree -e normal` on
`oxc_minifier` alone would miss
- **Self-validation**: `.github/workflows/ci.yml` and
`.github/workflows/miri.yml` are included in trigger paths so workflow
edits exercise the affected jobs
### Modes
**Include mode** (`--packages`): resolves transitive deps via `cargo
tree`, runs if changes affect any dep crate or additional paths.
**Exclude mode** (`--exclude`): skips only if ALL changed files are in
excluded crate directories (intentionally shallow — no `cargo tree`).
### Jobs updated
`test-wasm32-wasip1-threads`, `test-napi`, `test-napi-windows`,
`minification`, `allocs`, `lintgen`, `miri`
### Jobs intentionally unchanged
`conformance` (already uses `cargo tree`), `benchmark` (already uses
`cargo tree`), `ast_changes` (uses auto-generated watch list),
`test-ubuntu` (primary gate, runs everything), `typos`/`lint` (always
run)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Oxc's AST on JS side has a non-standard `hashbang` property. Previously in ESTree conformance tests, we skipped files with a hashbang.
Bump `estree-conformance` submodule to include https://github.com/oxc-project/estree-conformance/pull/183 which adds `hashbang` property to AST in snapshots.
We can now enable the tests which we previously skipped.
Our convention is that object properties are in source code order. Reverse `pattern` and `flags` properties of `regex` objects in ESTree tokens to align with this pattern.
Bump `estree-conformance` submodule to include https://github.com/oxc-project/estree-conformance/pull/182 which makes the same change in snapshots for conformance tests.
oxc-guard[bot]