---
title: "SWC v1.15.43 bringt den React Compiler als erstklassige Transformation, behebt einen stillen Template-Literal-Minifier-Bug und richtet `unsafe_math` an Terser aus"
description: "SWC v1.15.43, veröffentlicht am 2026-06-22 mit swc_core v71.0.3, liefert den experimentellen Rust-React-Compiler als konfigurierbare SWC-Transformation über .swcrc jsc.transform.reactCompiler (PR #11917, 54 Dateien, 12.986 Hinzufügungen); behebt einen stillen Template-Literal-Minifier-Bug, bei dem `compress` den Text nach der letzten Interpolation des linken Template-Literals beim Verketten zweier Template-Literale abschnitt (#11939); koppelt Number(x) -> +x an SOWOHL `unsafe: true` ALS AUCH `unsafe_math: true`, um mit terser v4.3.11+ übereinzustimmen (#11944, #11949); korrigiert den Geltungsbereich von ES2022-Privatfeld-Brand-Checks (#11953); und bringt sieben interne React-Compiler-Korrekturen (#11940, #11943, #11946, #11950, #11951, #11952, #11957) sowie eine Parser-Korrektur für No-Default-Builds (#11956) und einen Dok-Eintrag zum Sicherheitsumfang nicht vertrauenswürdiger Eingaben (#11937)."
date: 2026-06-23
image: "/images/heroes/2026-06-23--swc-v1-15-43-react-compiler-template-literal-bug.png"
author: lschvn
tags: ["tooling", "performance"]
tldr:
  - "SWC v1.15.43, veröffentlicht am 2026-06-22, liefert den Rust-React-Compiler als erstklassige konfigurierbare Transformation über das Feld `.swcrc` `jsc.transform.reactCompiler` (PR #11917, 54 Dateien, 12.986 Hinzufügungen). Die Transformation ist hinter einem Feature-Flag in `swc_core` v71.0.3 verriegelt und hängt derzeit von Git-Referenzen auf den vorgelagerten `facebook/react`-Rust-Workspace ab; die Integration ist die dritte React-Compiler-Integrationsgeschichte in der Tooling-Presse nach [Buns Bundler-Integration](/articles/2026-06-21--bun-react-compiler-bundler-integration-20x) (2026-06-20) und den [Oxc-v0.137-React-Compiler-Hooks](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) (2026-06-18)."
  - "Die Release behebt einen stillen Template-Literal-Minifier-Bug (#11939), bei dem die `compress`-Pass zwei Template-Literale verkettete und das `raw` des zusammengeführten Quasi aktualisierte, aber nicht sein `cooked`, wodurch der Text nach der letzten Interpolation des linken Template-Literals abgeschnitten wurde. Der Bug betraf jeden rspack- und rsbuild-Nutzer, der `compress: true` auf eine Template-Literal-Verkettung anwendete: `` `<b>${1}</b>` + `<i>${2}</i>` `` wurde stillschweigend zu `\"<b>1<i>2</i>\"` statt `\"<b>1</b><i>2</i>\"` minifiziert. Die Korrektur landet in `concat_tpl` und spiegelt nun die `raw`-Zusammenführung auf `cooked`."
  - "Die Release koppelt `Number(x)` zu `+x` ebenfalls an SOWOHL `unsafe: true` ALS AUCH `unsafe_math: true` (#11944, #11949), in Übereinstimmung mit terser seit v4.3.11. Der SWC-Minifier vor v1.15.43 führte die Umschreibung mit `unsafe: false` und `unsafe_math: true` durch, was die Parität mit terser unterbrach und die Bundle-Ausgabe zwischen SWC und terser auf derselben Quelle divergieren ließ. Die Korrektur ist eine Verhaltensänderung für Nutzer, die auf das SWC-Verhalten vertraut hatten; das Docs-Update und der Dok-Eintrag zum Sicherheitsumfang nicht vertrauenswürdiger Eingaben (#11937) machen die neue Grenze explizit."
faq:
  - question: "Was ist die Hauptfunktion in SWC v1.15.43?"
    answer: "Die Hauptfunktion ist die experimentelle Landung des Rust-React-Compilers als erstklassige SWC-Transformation (#11917, 54 Dateien, 12.986 Hinzufügungen). Die Integration fügt das Bridge-Crate `swc_ecma_react_compiler`, die AST- und Scope-Konvertierung zwischen SWC und React Compiler, die Konfiguration `.swcrc` `jsc.transform.reactCompiler`, die Diagnoseweiterleitung und die JS-/WASM-Optionstypen hinzu. Sie ist hinter einem Feature-Flag in `swc_core` v71.0.3 verriegelt und hängt derzeit von Git-Referenzen auf den vorgelagerten `facebook/react`-Rust-Workspace ab, den [facebook/react#36173](https://github.com/facebook/react/pull/36173) (gemerged am 2026-06-09) geliefert hat. Die ersten veröffentlichten Rust-Crates sind noch nicht verfügbar; bis dahin ist die Integration experimentell und noch nicht produktionsreif."
  - question: "Warum ist der Template-Literal-Minifier-Bug hervorzuheben?"
    answer: "Der Bug ist `fix(es/minifier): Preserve cooked when concatenating template literals` (#11939), und es ist die schlimmste Art von Minifier-Bug: stillschweigend, inhaltsabschneidend und kein Syntaxfehler. Wenn `compress` `a + b` faltete und beide Seiten Template-Literale waren, führte `concat_tpl` die Quasi-Grenzen zusammen, indem es `raw` aktualisierte, aber nicht `cooked`. Nachgelagerte Pässe (`eval_tpl_as_str`, `eval_nested_tpl`, `compress_tpl`) lesen `cooked`, um das Template zu einem String auszuwerten, sodass der Text nach der letzten Interpolation des linken Template-Literals stillschweigend abgeschnitten wurde. Beispiel: `` `<b>${1}</b>` + `<i>${2}</i>` `` wurde zu `\"<b>1<i>2</i>\"` statt `\"<b>1</b><i>2</i>\"` minifiziert. Der Bug betraf jeden rspack- und rsbuild-Nutzer, der `compress: true` auf eine Template-Literal-Verkettung anwendete; der Regressionstest in der PR führt den Original- und den minifizierten Code aus und vergleicht die Ausgabe."
  - question: "Wie verändert die unsafe_math-Korrektur die Bundle-Ausgabe?"
    answer: "Die Korrektur ist `fix(es/minifier): Gate Number(x) -> +x on unsafe flag` (#11944, Folge-PR #11949). Vor v1.15.43 schrieb der SWC-Minifier `Number(x)` zu `+x` um, sobald `unsafe_math: true` gesetzt war, selbst mit `unsafe: false`. Terser verlangt seit v4.3.11 SOWOHL `unsafe: true` ALS AUCH `unsafe_math: true` für dieselbe Umschreibung. Die Korrektur in v1.15.43 stellt die Parität wieder her: Die Umschreibung `Number(x)` zu `+x` wird nur ausgelöst, wenn beide Flags aktiv sind. Die Änderung ist verhaltensbrechend für Nutzer, die auf das SWC-Verhalten vertraut hatten: Mit `unsafe: false, unsafe_math: true` behält der Minifier nun `Number(x)` bei. Die erwartete minifizierte Ausgabe ist das ursprüngliche `Number(x)`."
  - question: "Was bedeutet die React-Compiler-Integration für rspack- und rsbuild-Nutzer?"
    answer: "rspack und rsbuild umschließen bereits den JS-Transformer von SWC, daher steht die React-Compiler-Transformation ihnen zur Verfügung, sobald sie das `react_compiler`-Feature in ihrem SWC-Build aktivieren und `jsc.transform.reactCompiler` in ihrer `.swcrc` setzen. Die Integration ist derzeit hinter dem Feature-Flag `react_compiler` in `swc_core` verriegelt, und das Bridge-Crate `swc_ecma_react_compiler` ist noch nicht im veröffentlichten crates.io-Index. Die PR-Beschreibung ist eindeutig: « Wait for the React Compiler Rust crates to be published, then replace the temporary git dependencies with published crate versions. » Bis dahin müssen nachgelagerte Konsumenten mit einem Git-Source-Build von `swc_core` rechnen, wenn sie experimentieren wollen."
  - question: "Welche weiteren React-Compiler-Korrekturen werden in dieser Release ausgeliefert?"
    answer: "Sieben interne React-Compiler-Korrekturen: `fix(es/react-compiler): Skip TypeScript this pseudo-params in scope collector` (#11940, mofeiZ) überspringt die synthetischen `this`-Parameter, die tsserver TypeScript-Methoden hinzufügt, damit der Scope-Collector sie nicht als echte Bindings behandelt; `fix(es/react-compiler): Scope ClassStaticBlock and TsModuleBlock as var boundaries` (#11943, mofeiZ) behandelt `ClassStaticBlock` (den `static { ... }`-Block in ES2022-Klassenrümpfen) und `TsModuleBlock` (den Rumpf von `namespace foo { ... }` und `module foo { ... }`) als Scope-Grenzen, sodass Deklarationen darin nicht in den umschließenden Scope leaken; `fix(react-compiler): Avoid reporting non-fatal success errors as diagnostics` (#11951, mofeiZ) hindert den Compiler daran, seine eigenen Erfolgsmarkierungen als sichtbare Fehler zu melden, was eine geräuschvolle `cargo test`-Ausgabe erzeugte; `fix(react-compiler): React compiler AST conversion for wrapped assignment targets` (#11952, mofeiZ) behandelt Zuweisungen an umschlossene Ausdrücke wie `(a.b).c = 1`, die die Bridge zuvor nicht konvertieren konnte; `fix(react-compiler): Disable parser default features` (#11957, mofeiZ) zieht den Feature-Umfang des Parsers enger, damit die Bridge keine Parser-Features hineinzieht, die mit dem Scope-Modell des React Compilers in Konflikt stehen; `chore(es/react-compiler): Update forked react compiler to 0.2.0` (#11946) aktualisiert den intern geforkten React Compiler auf 0.2.0; und `refactor(es/react-compiler): Preserve TS metadata during AST roundtrip` (#11950, mofeiZ) behält die TypeScript-spezifischen Metadaten auf der AST, wenn die Bridge zwischen SWC:s ESTree-geschmackter AST und der HIR des React Compilers hin- und hergeht."
  - question: "Was ist die ES2022-Brand-Check-Scope-Korrektur?"
    answer: "`fix(es/es2022): Correct scope for private property brand checks` (#11953) zieht das Scope-Tracking für den ES2022-Brand-Check von Privatfeldern enger, die `#field in obj`-Syntax, die entscheidet, ob ein Privatfeld von einer gegebenen Aufrufstelle aus zugänglich ist. Die Implementierung vor v1.15.43 verfolgte Brand-Checks auf der falschen Scope-Ebene, was dazu führte, dass einige Privatfeld-Zugriffe fälschlicherweise als Fehler gemeldet wurden und andere fälschlicherweise erlaubt waren. Die Korrektur scoped den Brand-Check auf die Klasse, in der das Feld deklariert ist, entsprechend der Spezifikation."
  - question: "Gibt es Breaking Changes in SWC v1.15.43?"
    answer: "Zwei Verhaltensänderungen, die Nutzer kennen sollten. Erstens verlangt `Number(x)` zu `+x` nun `unsafe: true` UND `unsafe_math: true` (#11944), in Übereinstimmung mit terser; das vorherige SWC-Verhalten war nur an `unsafe_math: true` gekoppelt, was seit v4.3.11 nicht mehr mit terser übereinstimmte. Zweitens entfernt die Parser-Korrektur für No-Default-Builds (#11956, dongzhi) die Default-Features des Parsers, wenn die React-Compiler-Integration aktiviert ist, was bedeutet, dass Parser-Features außerhalb des Scopes des React Compilers explizit aktiviert werden müssen. Keine der beiden Änderungen wird als Cargo-Crate-API-Bruch angekündigt, aber beide können die Bundle-Ausgabe verändern."
  - question: "Was ist der Docs-Eintrag zum Sicherheitsumfang nicht vertrauenswürdiger Eingaben?"
    answer: "`docs: Document untrusted input security scope` (#11937) ist eine reine Dokumentations-PR, die dem SWC-README einen expliziten Abschnitt hinzufügt, der klarstellt, was an die `parse`- und `process_print`-Eintrittspunkte von SWC gefüttert werden darf und was nicht. Der neue Abschnitt macht explizit, dass die Parsing- und Transformationsoberfläche von SWC nicht gegen adversariale Eingaben gehärtet ist: Eine fehlerhafte Quelldatei kann weiterhin einen Panic oder eine Out-of-Bounds-Allokation in nachgelagerten Transformationen auslösen. Der Docs-Eintrag ist eine nützliche Stolperfalle für Nutzer, die nicht vertrauenswürdigen Code einlesen; die Empfehlung ist, SWC in einem sandboxierten Subprozess auszuführen, wenn die Quelle nicht vertrauenswürdig ist."
---

[SWC v1.15.43](https://github.com/swc-project/swc/releases/tag/v1.15.43), veröffentlicht am 2026-06-22 mit `swc_core` v71.0.3, ist die erste SWC-Release, die den Rust-React-Compiler als konfigurierbare Transformation ausliefert, einen stillen Template-Literal-Minifier-Bug behebt, der jeden rspack- und rsbuild-Nutzer betraf, und das `unsafe_math`-Minifier-Flag mit terser v4.3.11+ in Einklang bringt. Die Release ist der siebzehnte `1.15.x`-Patch im [SWC-`1.15`-Zyklus](https://github.com/swc-project/swc/releases), der seit Anfang 2026 läuft, und der erste, der auf `swc_core` v71 landet.

Die Hauptarbeit verteilt sich auf drei Bereiche: die `swc_ecma_react_compiler`-Bridge, die den React Compiler zu einer erstklassigen SWC-Transformation macht, die `concat_tpl`-Korrektur für Template-Literale, die den stillen Minifier-Bug schließt, und die `unsafe_math`-Verhaltensänderung, die die Parität mit terser wiederherstellt. Sieben interne React-Compiler-Korrekturen, eine ES2022-Brand-Check-Scope-Korrektur, eine Parser-Korrektur für No-Default-Builds, ein Docs-Eintrag zum Sicherheitsumfang nicht vertrauenswürdiger Eingaben und die Entfernung der Production-Tracing-Hooks runden die Release ab.

## Der Template-Literal-Minifier-Bug

Die nutzerwirksamste Änderung in v1.15.43 ist `fix(es/minifier): Preserve cooked when concatenating template literals` ([#11939](https://github.com/swc-project/swc/pull/11939), kdy1). Die `concat_tpl`-Pass vor v1.15.43 faltete `a + b`, wenn beide Seiten Template-Literale waren, indem sie die Quasi-Grenzen zusammenführte: Das letzte Quasi des linken Templates wurde mit dem ersten Quasi des rechten Templates verkettet, und das zusammengeführte Quasi wurde mit `raw` gleich der Konkatenation der beiden `raw`-Strings emittiert. Der `cooked`-Slot blieb unangetastet.

Diese Asymmetrie war der Bug. Nachgelagerte Pässe (`eval_tpl_as_str`, `eval_nested_tpl`, `compress_tpl`) werten das Template über `cooked` zu einem String aus, sodass der Text nach der letzten Interpolation des linken Templates stillschweigend abgeschnitten wurde. Das Ergebnis war falsch, aber kein Syntaxfehler, also wurde es ausgeliefert.

Der Reproduzierer in der PR-Beschreibung ist `` `<b>${1}</b>` + `<i>${2}</i>` ``. Vor v1.15.43 emittierte der Minifier `<b>1<i>2</i>` (Anmerkung: Das schließende `</b>` fehlt). Die erwartete Ausgabe ist `<b>1</b><i>2</i>`. Dasselbe Muster betrifft jede Verkettung zweier Template-Literale, die beide mindestens eine Interpolation enthalten: `` `${1}px` + `${2}px` `` wurde mit dem falschen Trennzeichen zu `${1}${2}px` minifiziert. Der Bug wurde nur ausgelöst, wenn `compress: true` gesetzt war, was der Default im `optimization.minimize`-Pfad von rspack und im `output.overrideBrowserslist`-Minify-Pfad von rsbuild ist.

Die Korrektur aktualisiert `cooked` im `Tpl + Tpl`-Zweig von `concat_tpl` auf dieselbe Weise wie `raw`, und fällt auf `None` zurück, wenn das `cooked` einer Seite `None` ist (was eine ungültige Escape-Sequenz signalisiert). Die Schwesterzweige `Tpl + Str` und `Str + Tpl` führten `cooked` bereits korrekt zusammen; nur der `Tpl + Tpl`-Zweig vermisste die Zusammenführung. Die PR fügt einen Exec-Regressionstest hinzu, der den Original- und den minifizierten Code ausführt und die Ausgabe vergleicht, plus 49 Lib-Tests und 481 Exec-Tests im betroffenen `swc_ecma_minifier`-Crate.

Die PR-Beschreibung merkt an, dass der Bug auch über jeden Bundler auftauchte, der den JS-Minifier von SWC umschließt, einschließlich rspack und rsbuild. Nutzer, die die Korrektur an einer bekanntermaßen defekten Eingabe verifizieren möchten, können den kleinsten Reproduzierer aus der PR ausführen:

```js
require("@swc/core").minifySync("x = `a${0}]` + `${0}b`", { compress: true }).code
// vor v1.15.43:   x="a00b";
// nach v1.15.43: x="a0]0b";
```

## Der React Compiler als erstklassige SWC-Transformation

Die Hauptfunktion ist `feat(es/react-compiler): Add React Compiler` ([#11917](https://github.com/swc-project/swc/pull/11917), kdy1), die PR mit 12.986 Hinzufügungen und 54 Dateien, die den Rust-React-Compiler als konfigurierbare SWC-Transformation ausliefert. Die Integration fügt das Bridge-Crate `swc_ecma_react_compiler`, die Konvertierungsschicht für AST und Scope zwischen SWC und React Compiler, das Konfigurationsfeld `.swcrc` `jsc.transform.reactCompiler`, die Weiterleitung von Diagnosen aus der HIR des React Compilers an SWC:s `Handler` und die JS-/WASM-Optionstypen hinzu. Die Transformation ist hinter dem Feature-Flag `react_compiler` in `swc_core` v71.0.3 verriegelt und ist derzeit experimentell.

Der Rust-React-Compiler selbst ist die Arbeit in [facebook/react#36173](https://github.com/facebook/react/pull/36173) (gemerged am 2026-06-09, von [Mofei Z](https://github.com/mofeiZ) und dem React-Compiler-Team), das den ursprünglichen TypeScript-React-Compiler nach Rust portierte als Babel-AST-in / Babel-AST-out-Bibliothek mit drei Beispielintegrationen (Babel, Oxc, SWC). Die Architektur verwendet eine Babel-artige AST als öffentliche API und konvertiert zur und von der nativen Darstellung jeder Integration; SWC:s Bridge konvertiert zwischen SWC:s ESTree-geschmackter AST und der Rust-Babel-AST des React Compilers.

Die PR-Beschreibung ist eindeutig bezüglich der noch nicht veröffentlichten Crates-Abhängigkeit:

> Wait for the React Compiler Rust crates to be published, then replace the temporary git dependencies with published crate versions.

Bis dahin verwendet die Integration Git-Referenzen auf den vorgelagerten `facebook/react`-Rust-Workspace, was bedeutet, dass nachgelagerte Konsumenten (rspack, rsbuild, individuelle SWC-Nutzer) `swc_core` aus einer Git-Quelle bauen müssen, wenn sie experimentieren wollen. Der PR-Titel lautet `Add React Compiler` und der Eintrag im CHANGELOG ist `feat(es/react-compiler): Add React Compiler`; das Feature ist die dritte React-Compiler-Integrationsgeschichte in der Tooling-Presse, nach [Buns Bundler-Integration am 2026-06-20](/articles/2026-06-21--bun-react-compiler-bundler-integration-20x) (PR bun#32504) und den [Oxc-v0.137-React-Compiler-Treeshake-Hooks am 2026-06-18](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) (PR oxc#23471, oxc#23586).

Das nutzerseitige Konfigurationsfeld ist `jsc.transform.reactCompiler` in `.swcrc`. Die Form ist in der PR dokumentiert, aber noch nicht in den veröffentlichten Docs des `swc`-Crates; das experimentelle Flag ist die Art, sie zu aktivieren.

## Die unsafe_math-Verhaltensänderung

Die dritte Hauptänderung ist `fix(es/minifier): Gate Number(x) -> +x on unsafe flag` ([#11944](https://github.com/swc-project/swc/pull/11944), mit dem Follow-up in [#11949](https://github.com/swc-project/swc/pull/11949)). Der SWC-Minifier vor v1.15.43 schrieb `Number(x)` zu `+x` um, sobald `unsafe_math: true` gesetzt war, selbst mit `unsafe: false`. Terser verlangt seit v4.3.11 SOWOHL `unsafe: true` ALS AUCH `unsafe_math: true` für dieselbe Umschreibung.

Die Asymmetrie ist in [#11944](https://github.com/swc-project/swc/issues/11944) dokumentiert: Eine TypeScript-Quelle `export function foo(x) { return Number(x) }` mit `unsafe: false, unsafe_math: true` wird in SWC zu `+x` und in terser zu `Number(x)` minifiziert. Die beiden Ausgaben unterscheiden sich in jedem Bundle, das die Unsafe-Math-Only-Konfiguration verwendet, was die dokumentierte Terser-Option für eine « ausreichend sichere » Minifizierung mathematischer Ausdrücke ist.

Die Korrektur in v1.15.43 koppelt die Umschreibung an beide Flags, in Übereinstimmung mit terser. Die Änderung ist verhaltensbrechend für Nutzer, die auf das SWC-Verhalten vertraut hatten: Mit `unsafe: false, unsafe_math: true` behält der Minifier nun `Number(x)` bei. Die Korrektur ist im CHANGELOG dokumentiert und der Docs-Eintrag zum Sicherheitsumfang nicht vertrauenswürdiger Eingaben ([#11937](https://github.com/swc-project/swc/pull/11937)) fügt dem README einen Abschnitt hinzu, der die Sicherheitsgrenze für die `parse`- und `process_print`-Eintrittspunkte von SWC verdeutlicht.

## Die internen React-Compiler-Korrekturen

Sieben interne React-Compiler-Korrekturen landen neben der Bridge-Integration. Die Korrekturen sind kleiner als die Bridge selbst, aber sie sind die Arbeit, die die Bridge für reale Codebases nutzbar macht.

- `fix(es/react-compiler): Skip TypeScript this pseudo-params in scope collector` ([#11940](https://github.com/swc-project/swc/pull/11940), mofeiZ) weist den Scope-Collector an, die synthetischen `this`-Parameter zu ignorieren, die tsserver TypeScript-Methoden hinzufügt.
- `fix(es/react-compiler): Scope ClassStaticBlock and TsModuleBlock as var boundaries` ([#11943](https://github.com/swc-project/swc/pull/11943), mofeiZ) behandelt `ClassStaticBlock` (den `static { ... }`-Block in ES2022-Klassenrümpfen) und `TsModuleBlock` (den Rumpf von `namespace foo { ... }` und `module foo { ... }`) als Scope-Grenzen, sodass Deklarationen darin nicht in den umschließenden Scope leaken.
- `fix(react-compiler): Avoid reporting non-fatal success errors as diagnostics` ([#11951](https://github.com/swc-project/swc/pull/11951), mofeiZ) hindert den React Compiler daran, seine eigenen Erfolgsmarkierungen als sichtbare Fehler zu melden, was eine geräuschvolle `cargo test`-Ausgabe erzeugte.
- `fix(react-compiler): React compiler AST conversion for wrapped assignment targets` ([#11952](https://github.com/swc-project/swc/pull/11952), mofeiZ) behandelt Zuweisungen an umschlossene Ausdrücke wie `(a.b).c = 1`, die die Bridge zuvor nicht konvertieren konnte.
- `fix(react-compiler): Disable parser default features` ([#11957](https://github.com/swc-project/swc/pull/11957), mofeiZ) zieht den Feature-Umfang des Parsers enger, damit die Bridge keine Parser-Features hineinzieht, die mit dem Scope-Modell des React Compilers in Konflikt stehen.
- `chore(es/react-compiler): Update forked react compiler to 0.2.0` ([#11946](https://github.com/swc-project/swc/pull/11946)) aktualisiert den intern geforkten React Compiler auf 0.2.0, was die Bridge mit dem vorgelagerten Rust-Compiler in Einklang bringt.
- `refactor(es/react-compiler): Preserve TS metadata during AST roundtrip` ([#11950](https://github.com/swc-project/swc/pull/11950), mofeiZ) behält die TypeScript-spezifischen Metadaten auf der AST, wenn die Bridge zwischen SWC:s ESTree-geschmackter AST und der HIR des React Compilers hin- und hergeht.

Das Feature-Flag für den Re-Export der React-Compiler-Transformation ist `feat(swc): Gate react compiler re-export` ([#11941](https://github.com/swc-project/swc/pull/11941)), was bedeutet, dass das `react_compiler`-Modul des `swc`-Crates hinter demselben Feature-Flag `react_compiler` steht wie das Bridge-Crate. Nachgelagerte Nutzer, die die JS-/WASM-Bindings wollen, müssen beide aktivieren.

## Die ES2022-Brand-Check-Scope-Korrektur

`fix(es/es2022): Correct scope for private property brand checks` ([#11953](https://github.com/swc-project/swc/pull/11953)) zieht das Scope-Tracking für den ES2022-Privatfeld-Brand-Check enger. Die `#field in obj`-Syntax ist der Laufzeit-Check, der entscheidet, ob ein Privatfeld von einer gegebenen Aufrufstelle aus zugänglich ist; die Implementierung vor v1.15.43 verfolgte Brand-Checks auf der falschen Scope-Ebene, was dazu führte, dass einige Privatfeld-Zugriffe fälschlicherweise als Fehler gemeldet wurden und andere fälschlicherweise erlaubt waren. Die Korrektur scoped den Brand-Check auf die Klasse, in der das Feld deklariert ist, entsprechend der Spezifikation.

Die Korrektur ist die dritte ES2022-Korrektheitskorrektur im SWC-1.15-Zyklus, nach der `super`-Umschreibungskorrektur für private Methoden in v1.15.39 und der Scope-Korrektur für statische Initialisierungsblöcke in v1.15.41. ES2022-Privatfelder sind im Tooling weiterhin eine laufende Arbeit; die Korrektur ändert nicht die Parser-Oberfläche, nur die Transformations-Pass.

## Was v1.15.43 nicht ändert

Die Release ändert nicht die Parser-Oberfläche, die öffentliche API des React Compilers jenseits der neuen Transformation oder die öffentlichen APIs der `swc_ecma_*`-Crates. Die `CompressOptions`-Defaults des Minifiers bleiben die von v1.15.41; das neue `unsafe_math`-Verhalten ist an das bestehende `unsafe`-Flag gekoppelt. Der `swc_core`-v71.0.3-Bump ist die Arbeit, die das `react_compiler`-Feature-Flag in den veröffentlichten `swc_core`-Crates ausliefert; die v71-Linie ist die erste, die es trägt.

Die Release entfernt auch die Production-Tracing-Hooks (`refactor: Remove production tracing hooks`, [#11945](https://github.com/swc-project/swc/pull/11945), kdy1). Das SWC-Binary vor v1.15.43 lieferte Tracing-Hooks aus, die über die Umgebungsvariable `SWC_TRACE` für Production-Debugging aktiviert werden konnten; die Hooks fügten einen kleinen, aber messbaren Overhead bei jedem Parse-/Transform-Aufruf hinzu. Die Release v1.15.43 entfernt die Hooks vollständig, mit dem Trade-off, dass Production-Tracing nicht mehr ohne einen Debug-Build verfügbar ist.

## Was zu beobachten ist

Drei Folgeereignisse sind in den nächsten zwei bis sechs Wochen wahrscheinlich. Das erste ist die Veröffentlichung der React-Compiler-Rust-Crates auf crates.io, die die Integration von der temporären Git-Abhängigkeit zu einer veröffentlichten Version entkoppelt und rspack und rsbuild ermöglicht, die Transformation in ihren nächsten stabilen Releases auszuliefern. Das zweite ist die nächste `swc_core`-Minor-Release (v71.0.4 oder v71.1.0), die wahrscheinlich weitere HIR-Pässe des React Compilers als SWC-Transformationen exponieren wird. Das dritte ist die nächste Oxc-Crates-Release, die für Montag, den 2026-06-29 geplant ist und die erste Crates-Release außerhalb des v0.137-Zyklus sein wird; sie wird wahrscheinlich weitere React-Compiler-Hooks tragen, die die SWC-Bridge ergänzen.