SWC 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 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, 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 :
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, 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 (mergée le 2026-06-09, par Mofei Z 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 (PR bun#32504) et les hooks treeshake React Compiler d'Oxc v0.137 le 2026-06-18 (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, avec le suivi dans #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 : 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) 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, mofeiZ) demande au scope collector d'ignorer les paramètresthissynthétiques que tsserver ajoute aux méthodes TypeScript.fix(es/react-compiler): Scope ClassStaticBlock and TsModuleBlock as var boundaries(#11943, mofeiZ) traiteClassStaticBlock(le blocstatic { ... }dans les corps de classe ES2022) etTsModuleBlock(le corps denamespace foo { ... }etmodule 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 React Compiler de rapporter ses propres marqueurs de succès comme des erreurs visibles, ce qui produisait une sortiecargo testbruyante.fix(react-compiler): React compiler AST conversion for wrapped assignment targets(#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, 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, ce qui aligne la passerelle avec le compilateur Rust amont.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.
Le feature flag pour le re-export de la transformée React Compiler est feat(swc): Gate react compiler re-export (#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) 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, 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.
