---
title: "SWC v1.15.43 intègre le React Compiler comme transformée de première classe, corrige un bug silencieux du minifier sur les littéraux de gabarit, et aligne `unsafe_math` avec Terser"
description: "SWC v1.15.43, publié le 2026-06-22 avec swc_core v71.0.3, livre le React Compiler Rust comme transformée SWC configurable via .swcrc jsc.transform.reactCompiler (PR #11917, 54 fichiers, 12 986 ajouts) ; corrige un bug silencieux du minifier de littéraux de gabarit où `compress` supprimait le texte après la dernière interpolation du gabarit de gauche lors de la concaténation de deux littéraux de gabarit (#11939) ; conditionne Number(x) -> +x à la fois à `unsafe: true` ET `unsafe_math: true` pour suivre terser v4.3.11+ (#11944, #11949) ; corrige la portée des brand checks ES2022 pour les propriétés privées (#11953) ; et embarque sept corrections internes du React Compiler (#11940, #11943, #11946, #11950, #11951, #11952, #11957) ainsi qu'un correctif du parser pour autoriser les builds sans feature par défaut (#11956) et une entrée de doc sur la portée de sécurité des entrées non fiables (#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, publié le 2026-06-22, livre le React Compiler Rust comme transformée configurable de première classe via le champ `.swcrc` `jsc.transform.reactCompiler` (PR #11917, 54 fichiers, 12 986 ajouts). La transformée est verrouillée derrière un feature flag dans `swc_core` v71.0.3 et dépend actuellement de références git vers le workspace Rust amont de `facebook/react` ; l'intégration est la troisième intégration React Compiler dans la presse spécialisée après [l'intégration bundler de Bun](/articles/2026-06-21--bun-react-compiler-bundler-integration-20x) (2026-06-20) et les [hooks React Compiler d'Oxc v0.137](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) (2026-06-18)."
  - "La release corrige un bug silencieux du minifier de littéraux de gabarit (#11939) où la passe `compress` concaténait deux littéraux de gabarit et mettait à jour le `raw` du quasi fusionné mais pas son `cooked`, supprimant le texte qui suivait la dernière interpolation du gabarit de gauche. Le bug affectait chaque utilisateur de rspack et rsbuild qui exécutait `compress: true` sur une concaténation de littéraux de gabarit : `` `<b>${1}</b>` + `<i>${2}</i>` `` minifié en `\"<b>1<i>2</i>\"` au lieu de `\"<b>1</b><i>2</i>\"`, silencieusement. Le correctif atterrit dans `concat_tpl` et reproduit désormais la fusion de `raw` sur `cooked`."
  - "La release conditionne aussi `Number(x)` vers `+x` à la fois à `unsafe: true` ET `unsafe_math: true` (#11944, #11949), en alignement avec terser depuis v4.3.11. Le minifier SWC antérieur à v1.15.43 effectuait la réécriture avec `unsafe: false` et `unsafe_math: true`, ce qui rompait la parité avec terser et faisait diverger le bundle entre SWC et terser sur la même source. Le correctif est un changement de comportement pour les utilisateurs qui s'appuyaient sur le comportement SWC ; la mise à jour de doc et l'entrée de doc sur la portée de sécurité des entrées non fiables (#11937) rendent la nouvelle frontière explicite."
faq:
  - question: "Quelle est la fonctionnalité phare de SWC v1.15.43 ?"
    answer: "La fonctionnalité phare est l'arrivée expérimentale du React Compiler Rust comme transformée SWC de première classe (#11917, 54 fichiers, 12 986 ajouts). L'intégration ajoute le crate passerelle `swc_ecma_react_compiler`, la conversion d'AST et de portée entre SWC et le React Compiler, la configuration `.swcrc` `jsc.transform.reactCompiler`, le relayage des diagnostics, et les types d'options JS / WASM. Elle est verrouillée derrière un feature flag dans `swc_core` v71.0.3 et dépend actuellement de références git vers le workspace Rust amont de `facebook/react` que [facebook/react#36173](https://github.com/facebook/react/pull/36173) (mergée le 2026-06-09) a livré. Les premiers crates Rust publiés ne sont pas encore disponibles ; en attendant, l'intégration est expérimentale et pas encore prête pour la production."
  - question: "Pourquoi le bug de minifier sur les littéraux de gabarit mérite-t-il d'être signalé ?"
    answer: "Le bug est `fix(es/minifier): Preserve cooked when concatenating template literals` (#11939), et c'est le pire type de bug de minifier : silencieux, supprimant du contenu, et sans erreur de syntaxe. Quand `compress` fusionnait `a + b` avec deux littéraux de gabarit, `concat_tpl` fusionnait les quasis limites en mettant à jour `raw` mais pas `cooked`. Les passes en aval (`eval_tpl_as_str`, `eval_nested_tpl`, `compress_tpl`) lisent `cooked` pour évaluer le gabarit en chaîne, donc le texte après la dernière interpolation du gabarit de gauche était silencieusement supprimé. Exemple : `` `<b>${1}</b>` + `<i>${2}</i>` `` minifié en `\"<b>1<i>2</i>\"` au lieu de `\"<b>1</b><i>2</i>\"`. Le bug affectait chaque utilisateur de rspack et rsbuild qui exécutait `compress: true` sur une concaténation de littéraux de gabarit ; le test de régression de la PR exécute le code original et le code minifié et compare la sortie."
  - question: "Comment le correctif unsafe_math change-t-il la sortie du bundle ?"
    answer: "Le correctif est `fix(es/minifier): Gate Number(x) -> +x on unsafe flag` (#11944, suivi #11949). Avant v1.15.43, le minifier SWC réécrivait `Number(x)` en `+x` dès que `unsafe_math: true` était activé, même avec `unsafe: false`. Terser depuis v4.3.11 exigeait à la fois `unsafe: true` ET `unsafe_math: true` pour la même réécriture. Le correctif de v1.15.43 rétablit la parité : la réécriture `Number(x)` vers `+x` ne se déclenche que lorsque les deux flags sont actifs. Le changement casse le comportement des utilisateurs qui s'appuyaient sur le comportement SWC avec `unsafe: false` ; la sortie du bundle pour cette config devient désormais `Number(x)` au lieu de `+x`. La sortie minifiée attendue est le `Number(x)` d'origine."
  - question: "Que signifie l'intégration du React Compiler pour les utilisateurs de rspack et rsbuild ?"
    answer: "rspack et rsbuild enveloppent déjà le transformateur JS de SWC, donc la transformée React Compiler est disponible pour eux dès qu'ils activent la feature `react_compiler` dans leur build SWC et configurent `jsc.transform.reactCompiler` dans leur `.swcrc`. L'intégration est actuellement verrouillée derrière le feature flag `react_compiler` de `swc_core`, et la passerelle `swc_ecma_react_compiler` n'est pas encore indexée sur crates.io. La description de la PR est explicite : « Wait for the React Compiler Rust crates to be published, then replace the temporary git dependencies with published crate versions. » En attendant, les consommateurs en aval doivent s'attendre à un build depuis la source git de `swc_core` s'ils veulent expérimenter."
  - question: "Quelles autres corrections React Compiler sont livrées dans cette release ?"
    answer: "Sept corrections internes du React Compiler : `fix(es/react-compiler): Skip TypeScript this pseudo-params in scope collector` (#11940, mofeiZ) ignore les paramètres synthétiques `this` que tsserver ajoute aux méthodes TypeScript pour que le scope collector ne les traite pas comme des bindings réels ; `fix(es/react-compiler): Scope ClassStaticBlock and TsModuleBlock as var boundaries` (#11943, mofeiZ) traite les deux constructions `ClassStaticBlock` (le bloc `static { ... }` des corps de classe ES2022) et `TsModuleBlock` (le corps de `namespace foo { ... }` et `module foo { ... }`) comme des frontières de portée, donc les déclarations internes ne fuitent pas dans la portée englobante ; `fix(react-compiler): Avoid reporting non-fatal success errors as diagnostics` (#11951, mofeiZ) empêche le compilateur de rapporter ses propres marqueurs de succès comme des erreurs visibles ; `fix(react-compiler): React compiler AST conversion for wrapped assignment targets` (#11952, mofeiZ) corrige un vrai trou de correction où les affectations vers des expressions enveloppées (par exemple `(a.b).c = 1`) échouaient à la conversion ; `fix(react-compiler): Disable parser default features` (#11957, mofeiZ) resserre le jeu de features du parser pour que la passerelle ne tire pas des features incompatibles avec le modèle de portée du React Compiler ; `chore(es/react-compiler): Update forked react compiler to 0.2.0` (#11946) met à jour le React Compiler forké interne vers 0.2.0 ; et `refactor(es/react-compiler): Preserve TS metadata during AST roundtrip` (#11950, mofeiZ) conserve les métadonnées spécifiques à TypeScript sur l'AST quand la passerelle effectue l'aller-retour entre l'AST saveur ESTree de SWC et la HIR du React Compiler."
  - question: "Quel est le correctif de portée pour les brand checks ES2022 ?"
    answer: "`fix(es/es2022): Correct scope for private property brand checks` (#11953) resserre le suivi de portée pour le brand check ES2022 des champs privés, la syntaxe `#field in obj` qui décide si un champ privé est accessible depuis un site d'appel donné. L'implémentation antérieure à v1.15.43 suivait les brand checks au mauvais niveau de portée, ce qui faisait signaler à tort certaines erreurs sur des accès à des champs privés, et acceptait à tort certains autres. Le correctif scope le brand check à la classe où le champ est déclaré, conformément à la spec."
  - question: "Y a-t-il des changements cassants dans SWC v1.15.43 ?"
    answer: "Deux changements de comportement à connaître. Premièrement, `Number(x)` vers `+x` exige désormais `unsafe: true` ET `unsafe_math: true` (#11944), en alignement avec terser ; le comportement SWC antérieur était conditionné uniquement à `unsafe_math: true`, ce qui était en décalage avec terser depuis v4.3.11. Deuxièmement, le correctif parser no-default builds (#11956, dongzhi) supprime les features par défaut du parser quand l'intégration React Compiler est activée, ce qui signifie que les features du parser hors du scope du React Compiler doivent être activées explicitement. Aucun des deux changements n'est annoncé comme rupture d'API Cargo, mais les deux peuvent modifier la sortie du bundle."
  - question: "Qu'est-ce que l'entrée de doc sur la portée de sécurité des entrées non fiables ?"
    answer: "`docs: Document untrusted input security scope` (#11937) est une PR uniquement documentaire qui ajoute une section explicite au README de SWC clarifiant ce qui est ou n'est pas sûr d'alimenter dans les points d'entrée `parse` et `process_print` de SWC. La nouvelle section rend explicite que la surface d'analyse et de transformation de SWC n'est pas durcie contre les entrées adverses : un fichier source malformé peut toujours déclencher un panic ou une allocation hors bornes dans les transformées en aval. L'entrée de doc est un piège utile pour les utilisateurs qui ingèrent du code non fiable ; la recommandation est d'exécuter SWC dans un sous-processus sandboxé quand la source ne peut pas êtretrusted."
---

[SWC v1.15.43](https://github.com/swc-project/swc/releases/tag/v1.15.43), publié le 2026-06-22 avec `swc_core` v71.0.3, est la première release SWC qui livre le React Compiler Rust comme transformée configurable, corrige un bug silencieux du minifier de littéraux de gabarit qui affectait chaque utilisateur de rspack et rsbuild, et aligne le flag minifier `unsafe_math` avec terser v4.3.11+. La release est le dix-septième patch `1.15.x` dans le [cycle `1.15` de SWC](https://github.com/swc-project/swc/releases) qui court depuis début 2026 et le premier à atterrir sur `swc_core` v71.

Le travail principal se trouve dans trois endroits : la passerelle `swc_ecma_react_compiler` qui fait du React Compiler une transformée SWC de première classe, le correctif `concat_tpl` des littéraux de gabarit qui ferme le bug silencieux du minifier, et le changement de comportement `unsafe_math` qui rétablit la parité avec terser. Sept corrections internes du React Compiler, un correctif de portée du brand check ES2022, un correctif parser no-default builds, une entrée de doc sur la portée de sécurité des entrées non fiables, et la suppression des hooks de tracing en production complètent la release.

## Le bug de minifier sur les littéraux de gabarit

Le changement le plus impactant pour les utilisateurs dans v1.15.43 est `fix(es/minifier): Preserve cooked when concatenating template literals` ([#11939](https://github.com/swc-project/swc/pull/11939), kdy1). La passe `concat_tpl` antérieure à v1.15.43 fusionnait `a + b` quand les deux côtés étaient des littéraux de gabarit en fusionnant les quasis limites : le dernier quasi du gabarit de gauche était concaténé avec le premier quasi du gabarit de droite, et le quasi fusionné était émis avec `raw` égal à la concaténation des deux chaînes `raw`. Le slot `cooked` n'était pas touché.

Cette asymétrie était le bug. Les passes en aval (`eval_tpl_as_str`, `eval_nested_tpl`, `compress_tpl`) évaluent le gabarit en chaîne via `cooked`, donc le texte après la dernière interpolation du gabarit de gauche était silencieusement supprimé. Le résultat était faux mais sans erreur de syntaxe, donc il était livré.

Le reproducteur de la description de PR est `` `<b>${1}</b>` + `<i>${2}</i>` ``. Avant v1.15.43, le minifier émettait `<b>1<i>2</i>` (note : le `</b>` fermant a disparu). La sortie attendue est `<b>1</b><i>2</i>`. Le même pattern affecte toute concaténation de deux littéraux de gabarit qui contiennent tous les deux au moins une interpolation : `` `${1}px` + `${2}px` `` minifié en `${1}${2}px` avec le mauvais délimiteur. Le bug ne se déclenchait que lorsque `compress: true` était activé, qui est la valeur par défaut dans le chemin `optimization.minimize` de rspack et `output.overrideBrowserslist` minify de rsbuild.

Le correctif met à jour `cooked` dans la branche `Tpl + Tpl` de `concat_tpl` de la même manière que `raw`, en tombant à `None` si le `cooked` d'un côté est `None` (ce qui signale une séquence d'échappement invalide). Les branches sœurs `Tpl + Str` et `Str + Tpl` fusionnaient déjà correctement `cooked` ; seule la branche `Tpl + Tpl` manquait la fusion. La PR ajoute un test de régression exec qui exécute le code original et le code minifié et compare la sortie, plus 49 tests lib et 481 tests exec dans le crate `swc_ecma_minifier` affecté.

La description de la PR note que le bug remontait aussi via chaque bundler qui enveloppe le minifier JS de SWC, dont rspack et rsbuild. Les utilisateurs qui veulent vérifier le correctif sur une entrée connue défaillante peuvent exécuter le plus petit reproducteur de la PR :

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

## Le React Compiler comme transformée SWC de première classe

La fonctionnalité phare est `feat(es/react-compiler): Add React Compiler` ([#11917](https://github.com/swc-project/swc/pull/11917), kdy1), la PR à 12 986 ajouts et 54 fichiers qui livre le React Compiler Rust comme transformée SWC configurable. L'intégration ajoute le crate passerelle `swc_ecma_react_compiler`, la couche de conversion d'AST et de portée entre SWC et le React Compiler, le champ de configuration `.swcrc` `jsc.transform.reactCompiler`, le relayage des diagnostics depuis la HIR du React Compiler vers le `Handler` de SWC, et les types d'options JS / WASM. La transformée est verrouillée derrière le feature flag `react_compiler` dans `swc_core` v71.0.3 et est actuellement expérimentale.

Le React Compiler Rust lui-même est le travail de [facebook/react#36173](https://github.com/facebook/react/pull/36173) (mergée le 2026-06-09, par [Mofei Z](https://github.com/mofeiZ) et l'équipe React Compiler), qui a porté le React Compiler TypeScript original vers Rust comme bibliothèque Babel-AST-in / Babel-AST-out avec trois intégrations d'exemple (Babel, Oxc, SWC). L'architecture utilise un AST de style Babel comme API publique et convertit vers et depuis la représentation native de chaque intégration ; la passerelle de SWC convertit entre l'AST saveur ESTree de SWC et l'AST Rust Babel du React Compiler.

La description de la PR est explicite sur la dépendance crates non encore publiée :

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

En attendant, l'intégration utilise des références git vers le workspace Rust amont de `facebook/react`, ce qui signifie que les consommateurs en aval (rspack, rsbuild, utilisateurs SWC personnalisés) doivent builder `swc_core` depuis une source git s'ils veulent expérimenter. Le titre de la PR est `Add React Compiler` et l'entrée dans le CHANGELOG est `feat(es/react-compiler): Add React Compiler` ; la feature est le troisième article d'intégration React Compiler dans la presse spécialisée, après [l'intégration bundler de Bun le 2026-06-20](/articles/2026-06-21--bun-react-compiler-bundler-integration-20x) (PR bun#32504) et les [hooks treeshake React Compiler d'Oxc v0.137 le 2026-06-18](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) (PR oxc#23471, oxc#23586).

Le champ de configuration côté utilisateur est `jsc.transform.reactCompiler` dans `.swcrc`. La forme est documentée dans la PR mais pas encore dans les docs du crate `swc` publié ; le flag expérimental est la façon de l'activer.

## Le changement de comportement unsafe_math

Le troisième changement principal est `fix(es/minifier): Gate Number(x) -> +x on unsafe flag` ([#11944](https://github.com/swc-project/swc/pull/11944), avec le suivi dans [#11949](https://github.com/swc-project/swc/pull/11949)). Le minifier SWC antérieur à v1.15.43 réécrivait `Number(x)` en `+x` dès que `unsafe_math: true` était activé, même avec `unsafe: false`. Terser depuis v4.3.11 exigeait à la fois `unsafe: true` ET `unsafe_math: true` pour la même réécriture.

L'asymétrie est documentée dans [#11944](https://github.com/swc-project/swc/issues/11944) : une source TypeScript `export function foo(x) { return Number(x) }` avec `unsafe: false, unsafe_math: true` minifie en SWC en `+x` et en terser en `Number(x)`. Les deux sorties diffèrent sur chaque bundle qui utilise la config unsafe-math-only, qui est l'option Terser documentée pour une minification « suffisamment sûre » des expressions mathématiques.

Le correctif v1.15.43 conditionne la réécriture aux deux flags, en alignement avec terser. Le changement casse le comportement des utilisateurs qui s'appuyaient sur le comportement SWC : avec `unsafe: false, unsafe_math: true`, le minifier préserve désormais `Number(x)`. Le correctif est documenté dans le CHANGELOG et l'entrée de doc sur la portée de sécurité des entrées non fiables ([#11937](https://github.com/swc-project/swc/pull/11937)) ajoute une section au README qui clarifie la frontière de sécurité pour les points d'entrée `parse` et `process_print` de SWC.

## Les correctifs internes du React Compiler

Sept correctifs internes du React Compiler atterrissent à côté de l'intégration passerelle. Les correctifs sont plus petits que la passerelle elle-même mais ils sont le travail qui rend la passerelle utilisable sur des codebases réels.

- `fix(es/react-compiler): Skip TypeScript this pseudo-params in scope collector` ([#11940](https://github.com/swc-project/swc/pull/11940), mofeiZ) demande au scope collector d'ignorer les paramètres `this` synthétiques que tsserver ajoute aux méthodes TypeScript.
- `fix(es/react-compiler): Scope ClassStaticBlock and TsModuleBlock as var boundaries` ([#11943](https://github.com/swc-project/swc/pull/11943), mofeiZ) traite `ClassStaticBlock` (le bloc `static { ... }` dans les corps de classe ES2022) et `TsModuleBlock` (le corps de `namespace foo { ... }` et `module foo { ... }`) comme des frontières de portée, donc les déclarations internes ne fuitent pas dans la portée englobante.
- `fix(react-compiler): Avoid reporting non-fatal success errors as diagnostics` ([#11951](https://github.com/swc-project/swc/pull/11951), mofeiZ) empêche le React Compiler de rapporter ses propres marqueurs de succès comme des erreurs visibles, ce qui produisait une sortie `cargo test` bruyante.
- `fix(react-compiler): React compiler AST conversion for wrapped assignment targets` ([#11952](https://github.com/swc-project/swc/pull/11952), mofeiZ) gère les affectations vers des expressions enveloppées comme `(a.b).c = 1`, que la passerelle ne parvenait pas précédemment à convertir.
- `fix(react-compiler): Disable parser default features` ([#11957](https://github.com/swc-project/swc/pull/11957), mofeiZ) resserre le jeu de features du parser pour que la passerelle ne tire pas des features incompatibles avec le modèle de portée du React Compiler.
- `chore(es/react-compiler): Update forked react compiler to 0.2.0` ([#11946](https://github.com/swc-project/swc/pull/11946)) met à jour le React Compiler forké interne vers 0.2.0, ce qui aligne la passerelle avec le compilateur Rust amont.
- `refactor(es/react-compiler): Preserve TS metadata during AST roundtrip` ([#11950](https://github.com/swc-project/swc/pull/11950), mofeiZ) conserve les métadonnées spécifiques à TypeScript sur l'AST quand la passerelle effectue l'aller-retour entre l'AST saveur ESTree de SWC et la HIR du React Compiler.

Le feature flag pour le re-export de la transformée React Compiler est `feat(swc): Gate react compiler re-export` ([#11941](https://github.com/swc-project/swc/pull/11941)), ce qui signifie que le module `react_compiler` du crate `swc` est derrière le même feature flag `react_compiler` que le crate passerelle. Les utilisateurs en aval qui veulent les bindings JS / WASM doivent activer les deux.

## Le correctif de portée pour les brand checks ES2022

`fix(es/es2022): Correct scope for private property brand checks` ([#11953](https://github.com/swc-project/swc/pull/11953)) resserre le suivi de portée pour le brand check des champs privés ES2022. La syntaxe `#field in obj` est le check à l'exécution qui décide si un champ privé est accessible depuis un site d'appel donné ; l'implémentation antérieure à v1.15.43 suivait les brand checks au mauvais niveau de portée, ce qui faisait signaler à tort certaines erreurs sur des accès à des champs privés, et acceptait à tort certains autres. Le correctif scope le brand check à la classe où le champ est déclaré, conformément à la spec.

Le correctif est la troisième correction ES2022 dans le cycle SWC 1.15, après le correctif de réécriture `super` des méthodes privées en v1.15.39 et le correctif de portée des blocs d'initialisation statique en v1.15.41. Les champs privés ES2022 sont toujours un travail en cours dans l'outillage ; le correctif ne change pas la surface du parser, seulement la passe de transformation.

## Ce que v1.15.43 ne change pas

La release ne change pas la surface du parser, l'API publique du React Compiler au-delà de la nouvelle transformée, ou les API publiques des crates `swc_ecma_*`. Les valeurs par défaut `CompressOptions` du minifier restent celles de v1.15.41 ; le nouveau comportement `unsafe_math` est conditionné au flag `unsafe` existant. Le bump `swc_core` v71.0.3 est le travail qui livre le feature flag `react_compiler` dans les crates `swc_core` publiés ; la ligne v71 est la première à le porter.

La release supprime aussi les hooks de tracing en production (`refactor: Remove production tracing hooks`, [#11945](https://github.com/swc-project/swc/pull/11945), kdy1). Le binaire SWC antérieur à v1.15.43 embarquait des hooks de tracing activables via la variable d'environnement `SWC_TRACE` pour le débogage en production ; les hooks ajoutaient un coût faible mais mesurable sur chaque appel parse / transform. La release v1.15.43 supprime les hooks entièrement, au prix d'un tracing en production qui n'est plus disponible sans un build debug.

## À surveiller

Trois suites sont probables dans les deux à six prochaines semaines. La première est la publication des crates Rust du React Compiler sur crates.io, qui débloque l'intégration de la dépendance git temporaire vers une version publiée et permet à rspack et rsbuild de livrer la transformée dans leurs prochaines releases stables. La deuxième est la prochaine release mineure `swc_core` (v71.0.4 ou v71.1.0), qui est susceptible de livrer davantage de passes HIR du React Compiler exposées comme transformées SWC. La troisième est la prochaine release crates d'Oxc, prévue lundi 2026-06-29 et qui sera la première release crates hors du cycle v0.137 ; elle est susceptible de porter davantage de hooks React Compiler qui complètent la passerelle SWC.