Latest Results
feat(bindings): add `lint` / `lintSync` API to `@swc/react-compiler` (#11965)
**Description:**
Adds a dedicated `lint`/`lintSync` API to `@swc/react-compiler` for
running React Compiler's lint pass and getting back structured
diagnostics, without compiling.
This replaces the original approach in this PR (attaching
`reactCompilerDiagnostics` to `@swc/core`'s thrown
`transform`/`transformSync` error), per feedback from @kdy1 and
@magic-akari — a dedicated API scoped to React Compiler, rather than
extending `@swc/core`'s generic error shape. That change is fully
reverted here.
```ts
import { lint, lintSync } from '@swc/react-compiler'
lintSync(code: string, syntax?: ParserConfig): Diagnostic[]
lint(code: string, syntax?: ParserConfig): Promise<Diagnostic[]>
```
- `code` is the raw source text.
- `syntax` is the same `ParserConfig` shape `@swc/core`'s `jsc.parser`
already accepts (`@swc/types`), letting callers opt into
TypeScript/JSX/TSX/decorators per file. Defaults to plain ECMAScript
when omitted, matching `@swc/core`'s own default.
- Each `Diagnostic` includes `severity`, `message`, `ruleId`,
`category`, `reason`, `description`, `loc` (start/end line/column/index
+ filename/identifierName), and `details`.
Motivating use case: building fast, per-rule ESLint integrations on top
of the Rust-based compiler (one `lintSync` call per file, fanned out to
N independently-configurable ESLint rules by `ruleId`) instead of
re-implementing lint checks in JS.
React Compiler's own compile options (`compilationMode`, `target`,
`panicThreshold`, `gating`, `environment`, ...) are intentionally not
exposed yet — investigated and left as-is for now (e.g. raising
`panicThreshold` would route more results through a fallback path that
loses `ruleId`/`category`/`loc`, working against the point of this API).
Validation:
- `cargo fmt --all`
- `cargo clippy --all --all-targets -- -D warnings`
- `cargo test -p swc_ecma_react_compiler`
- `cargo test -p binding_react_compiler_node`
- `cargo check -p binding_core_node` (confirms the revert didn't leave
`@swc/core`'s napi binding referencing removed types)
- `pnpm --filter @swc/react-compiler build:dev && pnpm --filter
@swc/react-compiler test`
**BREAKING CHANGE:**
None. `lint`/`lintSync` are new; the reverted `@swc/core` changes were
never released.
**Related issue (if exists):**
None.
---------
Co-authored-by: Oz <oz-agent@warp.dev>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: DongYun Kang <kdy.1997.dev@gmail.com> fix(es/react-compiler): Correct catch and parameter scope resolution (#11985)
**Description:**
Fixes React Compiler scope conversion for catch and parameter bindings.
The bug from #11982 was exposed by compiling an async `useCallback` with
`catch (error) { return error; }`: the converted scope info did not
consistently model the catch parameter as a value binding, so references
to the catch value could be left unresolved and produce incorrect
compiled output.
This PR updates `SemanticBuilder` so declaration-space flags carry
value-ness explicitly, with marker flags (`Param`, `CatchVariable`,
`FunctionExpression`) layered onto value-bearing flags. Catch bindings
stay in the catch scope and can be resolved from catch bodies and catch
parameter initializers.
It also models parameter initializers and destructuring patterns with a
temporary internal resolution scope. Function, arrow, constructor,
accessor, and catch parameters now resolve references before body
bindings are collected, so defaults and computed pattern keys observe
the intended lexical visibility: function expression names and parameter
bindings are visible, while body bindings do not shadow parameter
initialization. These internal parameter scopes are skipped when
emitting React Compiler `ScopeInfo`, preserving the public scope tree.
Coverage includes:
- the async `useCallback` catch-binding compile-pass fixture for #11982
- catch destructuring with computed keys and initializer references
- function parameter defaults resolving to outer bindings, later
parameters, or named function expressions
- named function expressions shadowed by params or body `var`
declarations
**Related issue:**
- Closes #11982 Latest Branches
0%
refactor/es-module-records +3%
imjordanxd:feat/react-compiler-lint-diagnostics 0%
© 2026 CodSpeed Technology