## Summary
Removes React Compiler from the `oxc-transform` napi binding entirely.
It was previously exposed as a `reactCompiler` transform option (added
in #22942, shipped in 0.135.0 / 0.136.0).
**Why not feature-gate it instead?** Gating React Compiler in the
binding can't produce a consistent `index.d.ts`:
- Keep the option types unconditionally → the published `.d.ts`
advertises a `reactCompiler` option that a default (feature-off) build
silently ignores.
- Gate the type surface too → CI's `build-test` (which would enable the
feature) regenerates a `.d.ts` that no longer matches the checked-in
lean one, breaking `git diff --exit-code`.
Removing it from the binding sidesteps both. React Compiler stays
available to the Rust `oxc_transformer` crate behind its own
`react_compiler` feature — only the napi binding loses it.
## Changes
- Drop the `reactCompiler` option and the `ReactCompilerOptions` /
`ReactCompilerGating` / `ReactCompilerDynamicGating` types.
- Remove the `oxc_react_compiler` dependency and stop enabling `oxc`'s
`react_compiler` feature.
- Delete `src/react_compiler.rs` and `test/reactCompiler.test.ts`.
- Regenerate `index.d.ts` (drops the three interfaces + the field;
`index.js` is unchanged — they were type-only).
## Breaking change
`oxc-transform` no longer accepts the `reactCompiler` option. It shipped
in 0.135.0 and 0.136.0.
## Verification
- `cargo check` + `cargo clippy --all-targets`: clean.
- `cargo shear`: no issues; `Cargo.lock` drops only the
`oxc_transform_napi → oxc_react_compiler` edge.
- No remaining `reactCompiler` / `ReactCompilerOptions` references
anywhere else in the repo.
- `pnpm build-test` + `pnpm test`: 53/53 pass (the React Compiler test
is removed).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Summary
Introduces `oxc_diagnostics::Diagnostics` — a `Vec<OxcDiagnostic>` newtype that knows the difference between errors and warnings — and makes it the standard diagnostics return value across oxc.
- **New type**: `Diagnostics` with `has_errors()`, `has_warnings()`, `errors()`, `warnings()`, plus `Vec`-like ergonomics (Deref, `IntoIterator`, `Extend`, `From`/`Into<Vec>`) so most call sites are unchanged.
- **Return types**: `ParserReturn`, `SemanticBuilderReturn`, `IsolatedDeclarationsReturn`, the React Compiler `TransformResult`/`LintResult`, and `TransformerReturn` now expose `diagnostics: Diagnostics` instead of `errors: Vec<OxcDiagnostic>` (the React Compiler's separate `errors`/`warnings` are merged into one severity-tagged list).
- **Behaviour**: a React Compiler **error** now stops the transform (no output), while **warnings** flow through and the transform continues. `compile()` aborts codegen only when `diagnostics.has_errors()` — warnings alone no longer abort (previously any diagnostic did).
## Breaking change
Consumers reading `*.errors` on these return values must read `*.diagnostics`. React Compiler consumers that read `.errors`/`.warnings` separately should use `diagnostics.has_errors()` / `diagnostics.errors()` / `diagnostics.warnings()`.
Parser/semantic/isolated-declarations fatality is otherwise unchanged. Builds on the React Compiler transform feature (#23201).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Summary
Closes#13398.
The styled-components transform's `transpileTemplateLiterals` option rewrites tagged template literals into the array-call form:
```js
// in
styled.div`width: 100%;`
// out — transpileTemplateLiterals: true
styled.div(["width: 100%;"])
```
This form is only more compact when template literals are *also* down-levelled to ES5 — which is why `babel-plugin-styled-components` enables it by default, to pre-empt Babel's verbose `_taggedTemplateLiteral` output. Oxc does not down-level template literals below ES6, so the array-call form is strictly *larger* than leaving the tagged template untouched.
This PR flips the default to `false`, as agreed with @Dunqing in #13398.
## Changes
- `StyledComponentsOptions::transpile_template_literals` now defaults to `false` (both the `serde` field default and the `Default` impl), with docs explaining why.
- napi: `transpileTemplateLiterals` is documented `@default false` (`transformer.rs` + `index.d.ts`), and the styled-components napi test snapshot now reflects the non-transpiled default output.
- Conformance fixtures that relied on the old default and whose reference output is transpiled now pin `transpileTemplateLiterals: true`, so they keep matching `babel-plugin-styled-components`' reference output. The conformance snapshot is unchanged — `plugin-styled-components` stays at 25/40.
## Breaking change
`transpileTemplateLiterals` now defaults to `false`. Pass `transpileTemplateLiterals: true` to restore the previous behavior.
🤖 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
Adds a `strictNullChecks` field to `DecoratorOptions` (default `true`)
that
controls whether `null` and `undefined` are elided from union
`design:type`
metadata. The default preserves tsc strict semantics (`T | null` →
`Object`);
setting `strictNullChecks: false` matches
babel-plugin-transform-typescript-metadata
and tsc with `--strictNullChecks=false`, emitting the underlying
primitive
(`T | null` → `String` when `T = string`).
Originally this PR unconditionally elided null/undefined. Per @Dunqing's
review, it's now opt-in so the default-strict behaviour is preserved.
## Motivation
When `strictNullChecks` is off, tsc emits the constructor of the
underlying
primitive. babel-plugin-transform-typescript-metadata always elides null
and
undefined regardless of tsconfig. Downstream consumers (NestJS Swagger,
class-validator, TypeORM, AutoMapper) treat `Object` as "no metadata"
and
silently drop fields, so users with `strictNullChecks: false` (common in
older codebases) get worse behaviour under OXC than under tsc/babel.
## Implementation
```rust
pub struct DecoratorOptions {
pub legacy: bool,
pub emit_decorator_metadata: bool,
#[serde(default = "default_as_true")]
pub strict_null_checks: bool, // default true
}
```
Threaded through `Decorator::new(options) →
LegacyDecorator::new(&options) →
LegacyDecoratorMetadata::new(&options)` (matching the established
`TypeScript::new(&TypeScriptOptions)` precedent), and gated in
`serialize_union_or_intersection_constituents`:
```rust
TSType::TSNullKeyword(_) | TSType::TSUndefinedKeyword(_)
if !is_intersection && !self.strict_null_checks => continue,
```
Mirrored at the napi binding (`napi/transform/src/transformer.rs`) so
direct
Node consumers can flip it the day this lands. Consumers that wire
tsconfig
(rolldown, bundlers) can forward `compilerOptions.strictNullChecks` to
it.
## Behaviour matrix
| Source | `strictNullChecks: true` (default) | `strictNullChecks:
false` |
|---|---|---|
| `string \| null` | `Object` (matches tsc strict, current behaviour) |
`String` (matches babel, tsc non-strict) |
| `number \| undefined` | `Object` | `Number` |
| `boolean \| null \| undefined` | `Object` | `Boolean` |
| `null \| undefined` | `void 0` | `void 0` |
| `string \| number` | `Object` | `Object` (distinct primitives) |
| `string & null` | `Object` | `Object` (intersection unchanged) |
## Test plan
- [x] 7 unit tests in `tests/integrations/decorator_metadata.rs`
covering
`T | null` under both `strictNullChecks: true` (emits `Object`, current
behaviour) and `strictNullChecks: false` (emits primitive), plus
`T | undefined`, `T | null | undefined`, the `null | undefined`
void-only
case, the `string | number` distinct-primitive case (still `Object`),
and
the intersection-with-null regression
- [x] New conformance fixture `oxc/metadata/nullable-union/` with its
own
`options.json` setting `strictNullChecks: false`
- [x] `cargo test -p oxc_transformer` passes (31 unit + 11 integration)
- [x] `cargo run -p oxc_transform_conformance` shows 0 regressions;
baseline
fixtures still pass plus the new `nullable-union`
- [x] `cargo fmt -p oxc_transformer -p oxc_transform_napi` and
`cargo clippy --tests --no-deps` clean
AI assistance was used in writing this patch and tests; the contributor
has
reviewed and tested locally.
---------
Co-authored-by: Dunqing <dengqing0821@gmail.com>
Surface the TypeScript transformer's `optimize_const_enums` and
`optimize_enums` options through the napi bindings so JavaScript
consumers can opt into const enum inlining and regular (non-const)
enum inlining. Previously both were hardcoded to `false` in the
`From<TypeScriptOptions>` conversion, making them unreachable from JS.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
## Summary
- Implements speculative/unambiguous parsing for `.js`, `.jsx`, `.ts`, and `.tsx` files
- Instead of assuming module or script upfront, parses with `ModuleKind::Unambiguous` and upgrades to module mode when ESM syntax is detected
- ESM indicators: `import`, `export`, `import.meta` (NOT top-level await alone)
- Defers top-level await errors until module type is resolved
- Vue loader upgrades unambiguous scripts to module mode
- Updates linter tests to use explicit ESM extensions (`.mjs`/`.mts`) where needed
## Test plan
- [x] All parser tests pass
- [x] All linter tests pass
- [x] All semantic tests pass
- [x] Coverage conformance tests updated
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Investigated the reported issue where import source specifiers with
special characters (like quotes) were claimed to not be escaped in the
inject global variables transformer.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: sapphi-red <49056869+sapphi-red@users.noreply.github.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
fixes#12796
* Added target `ES2026`
* Moves the explicit resource management feature from proposals to ES2026, as it is now a finalized ECMAScript 2026 feature.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
## Summary
This PR adds an async transform function to the NAPI transform package, following the same pattern used in the parser package for consistency.
Closes#10900
## Changes
- Added `transformAsync` function that returns a Promise
- Implemented `TransformTask` struct with `napi::Task` trait
- Reuses existing transform logic from the synchronous version
- Added comprehensive tests to verify async behavior
## Test Plan
Added tests in `test/transform.test.ts` that verify:
- Async function works correctly
- Produces identical results to sync version
- Properly handles errors
All existing tests continue to pass.
🤖 Generated with [Claude Code](https://claude.ai/code)
closes#13174
This should reduce sourcemap memory usage by a huge amount.
These tokens were added in esbuild for code coverage: https://github.com/evanw/esbuild/commit/c4d45e6b5766b1a1b56bf24b7dadb240de91332b
But esbuild has an optimization to not generate these tokens when `}` is not on the same line
```
if class.CloseBraceLoc.Start > class.BodyLoc.Start {
p.addSourceMapping(class.CloseBraceLoc)
}
```
We should revisit these tokens later in the future.
* close https://github.com/oxc-project/oxc/issues/11296
Both `Transformer` and `Minifier` have a minimum ES version support of `ES2015`. However, we can set the `ESTarget` to `ES5` now, which might mislead users into thinking we already support `ES5`, so for now, let's remove the `ESTarget::ES5` option to eliminate the confusion.
Suggested by @shulaoda
* close https://github.com/rolldown/rolldown/issues/5374
Example:
Input:
```ts
function myPropertyDecorator() {
return (target: any, propertyKey: number) => {
console.log(target.constructor.modelName, propertyKey);
};
}
class Test {
public static modelName = 'Test';
@myPropertyDecorator()
public myProperty = 1;
}
const instance = new Test();
export default instance;
```
Output diff:
```diff
function myPropertyDecorator() {
return (target, propertyKey) => {
console.log(target.constructor.modelName, propertyKey);
};
}
class Test {
constructor() {
babelHelpers.defineProperty(this, "myProperty", 1);
}
}
-babelHelpers.decorate([myPropertyDecorator()], Test.prototype, "myProperty", void 0);
-babelHelpers.defineProperty(Test, "modelName", "Test");
+babelHelpers.defineProperty(Test, "modelName", "Test");
+babelHelpers.decorate([myPropertyDecorator()], Test.prototype, "myProperty", void 0);
const instance = new Test();
export default instance;
```
The cause is that we transform class fields and decorators in two different plugins, and the decorator plugin should be transformed first, and then run the class-properties plugin, because class-properties might erase some decorator information. However, this cause transformed decorators injected before transformed class fields.
This PR fixes this problem by collecting all transformed decorators that wait for injection, and injecting them in batch after the `class-properties` plugin has run.
Control printing of comments more precisely via more options:
The logic change here is that jsdoc is no longer part of annotation
comments.
```rust
pub struct CommentOptions {
/// Print normal comments that do not have special meanings.
///
/// At present only statement level comments are printed.
///
/// Default is `true`.
pub normal: bool,
/// Print jsdoc comments.
///
/// * jsdoc: `/** jsdoc */`
///
/// Default is `true`.
pub jsdoc: bool,
/// Print annotation comments.
///
/// * pure: `/* #__PURE__ */` and `/* #__NO_SIDE_EFFECTS__ */`
/// * webpack: `/* webpackChunkName */`
/// * vite: `/* @vite-ignore */`
/// * coverage: `v8 ignore`, `c8 ignore`, `node:coverage`, `istanbul ignore`
///
/// Default is `true`.
pub annotation: bool,
/// Print legal comments.
///
/// * starts with `//!` or `/*!`.
/// * contains `/* @license */` or `/* @preserve */`
///
/// Default is [LegalComment::Inline].
pub legal: LegalComment,
}
```
closes#12030
related https://github.com/rolldown/tsdown/issues/357
Aligning with https://github.com/vitejs/vite/pull/18983
I manually verified the test case output matches with the ones in Vite repo.
~I add a new TODO about "export default" getter, but this difference existed already. I plan to fix this separately.~ (EDIT: It turned out Vite's transform is the wrong one https://github.com/vitejs/vite/issues/19834.)
Expose a `moduleRunnerTransform` function that `Vite` can directly use it to speed-up ssr transform. In this way, `Vitest` also benefits without having to wait for `rolldown-vite`.
close: https://github.com/rolldown/rolldown/issues/3728#issuecomment-2693097569
Before, we need to make sure all metadata decorators are placed after parameter decorators. I tried to push them to the last parameter decorators. But it caused it to be incorrectly wrapped by `decorateParam`.
I re-check decorate helper implementation, I didn't see any potential runtime will caused by the decorators order. So I decide to always push to method's decorators
Before:
```js
_decorate([
_decorateParam(0, dce),
_decorateParam(0, _decorateMetadata("design:type", Function)),
_decorateParam(0, _decorateMetadata("design:paramtypes", [Object])),
_decorateParam(0, _decorateMetadata("design:returntype", void 0))
], C.prototype, "method", null);
```
After:
```js
_decorate([
_decorateMetadata("design:type", Function),
_decorateMetadata("design:paramtypes", [Object]),
_decorateMetadata("design:returntype", void 0),
_decorateParam(0, dce)
], C.prototype, "method", null);
```
Boshen