SPFx 1.23.2 : mettre à jour n'est pas changer un numéro

SharePoint Framework 1.23.2 est sortie le 30 juin 2026 sous la forme d'un minor bump : elle corrige des vulnérabilités npm et quelques problèmes signalés. Cela ressemble à une mise à jour de routine, de celles que l'on fait sans réfléchir. Ce n'en est pas une.

L'indice se trouve dans la version précédente. La 1.23.1 a été publiée puis retirée de npm pour cause de régressions. Dans un framework mature, une version sortie de la circulation est un avertissement : le risque, quand on met à jour SPFx, ne vient presque jamais du runtime de SharePoint, il vient du build. Cet article expose ce qui a changé, ce qui s'est cassé et ce qui va encore casser, avec le code montrant ce que c'était, ce que c'est, et ce que ce sera.

Ce qui casse, ce n'est pas SharePoint, c'est le build

Un web part SPFx tourne dans le navigateur, au sein d'une page SharePoint, et cette partie est stable depuis des années. Ce que Microsoft déplace, et en profondeur, c'est la chaîne de build : l'outillage qui compile le TypeScript, traite le Sass et empaquette le .sppkg. Mettre à jour les paquets SPFx et migrer le processus de build sont deux opérations liées, mais distinctes, et c'est la seconde qui casse les builds.

D'où la règle numéro un : une mise à jour SPFx n'a rien de mécanique. On ne change pas le numéro dans package.json en s'attendant à ce que tout compile ; Microsoft prévient elle-même que cela provoque des échecs de build. Voici les quatre endroits où cela mord, et ce qu'il faut faire à chacun.

Gulp est en train de partir

Le changement structurel, c'est la fin de Gulp. Jusqu'à la 1.21, Gulp orchestrait tout. À partir de la 1.22, les nouveaux projets sont passés à Heft, qui s'appuie toujours sur webpack en dessous mais le pilote lui-même ; le gulpfile.js a cessé d'être compatible et le config.json a disparu. En 1.23, un projet existant peut encore rester sur Gulp. En 1.24, Gulp ne sera officiellement plus pris en charge.

# WAS (SPFx 1.21 and earlier): Gulp orchestrated the whole build.
gulp bundle --ship
gulp package-solution --ship

# IS (SPFx 1.22-1.23): Heft orchestrates webpack. gulpfile.js and config.json
# are gone; the commands are plain npm scripts.
npm run build
npm run package

# WILL BE (SPFx 1.24): the Gulp toolchain is officially unsupported, and the
# Yeoman generator gives way to the new SPFx CLI.
npm install -g @microsoft/spfx-cli

Parallèlement, Yeoman est remplacé par le nouveau @microsoft/spfx-cli, encore en préversion, dont la disponibilité générale est prévue pour la 1.25, en septembre. Autrement dit, toucher aux paquets et migrer le build sont deux projets distincts. On met d'abord à jour vers la 1.23.2, puis on planifie à part la migration vers Heft, avec des tests.

Sass a changé sans prévenir

La régression la plus difficile à repérer en 1.23 concerne Sass, et Microsoft elle-même la classe comme non documentée (issue #10854). Des imports qui fonctionnaient en 1.22 ne se résolvent plus : le préfixe ~, les bare specifiers et importIncludePaths cessent de fonctionner. Un projet au Sass un peu sérieux compile en 1.22 et échoue en 1.23 sans qu'une seule ligne de code ait changé.

// WAS (worked in SPFx 1.22): the webpack tilde and importIncludePaths.
@use "~@scope/package/styles";

@use "sass:meta";
.card { @include meta.load-css("~@scope/package/styles"); }

// IS (SPFx 1.23, issue #10854): the tilde and bare specifiers stop resolving,
// and importIncludePaths is gone. Import npm packages with the pkg: scheme.
@use "pkg:@scope/package/styles";

@use "sass:meta";
.card { @include meta.load-css("pkg:@scope/package/styles"); }

La marche à suivre : le schéma pkg: pour importer les paquets npm, et une revue de tous les meta.load-css(). Le même lot contient d'autres surprises : les source maps SCSS pointaient vers du CSS intermédiaire au lieu du .scss d'origine (#10831), et de simples fichiers .scss généraient des types CSS Module alors que webpack les traitait comme globaux (#10832). La 1.23.2 donne ces points pour corrigés, mais certaines issues restent ouvertes sur le tracker : testez avant de supposer que c'est résolu dans votre cas.

npm audit fix --force fait plus de mal que de bien

La 1.23.2 a corrigé les vulnérabilités critiques et élevées ; il reste quelques vulnérabilités modérées dans des dépendances externes. Le réflexe instinctif, lancer npm audit fix --force, est le mauvais, et Microsoft déconseille expressément de le faire : la commande réécrit des paquets transitifs que Microsoft a testés et vous laisse un build qui ne se reproduit plus.

# WAS (the footgun Microsoft tells you not to pull): rewrites the transitive
# packages Microsoft tested, and leaves you a build that no longer reproduces.
npm audit fix --force

# IS (look before you touch): most vulnerable packages are build-time only, and
# node_modules never ships inside the .sppkg.
npm audit --omit=dev
npm ls the-flagged-package
npm explain the-flagged-package

La distinction qui compte : la plupart des dépendances vulnérables font partie de l'environnement de build, et le node_modules ne part jamais dans le .sppkg. Une vulnérabilité dans un outil local n'est pas une vulnérabilité en production sur SharePoint. Avant de toucher à quoi que ce soit, vérifiez si la dépendance relève uniquement du développement, si elle finit dans le bundle final, et qui l'a introduite.

Épingler les versions, pas @latest

Voici la leçon de la 1.23.1 : dans un pipeline, @latest est une bombe à retardement. Si le build était tombé sur la 1.23.1 le mauvais jour, il aurait installé une version que Microsoft a fini par retirer. On épingle donc des versions exactes, et on installe React exactement comme l'indique la matrice, avec --save-exact, car une mauvaise version de React échoue en silence, sans erreur de build.

# The 1.23.1 lesson: it was delisted from npm for regressions. In a pipeline,
# @latest is a time bomb. Pin exact versions.
npm install react@17.0.1 react-dom@17.0.1 --save-exact
# SPFx 1.23.2 matrix: Node v22, TypeScript up to 5.8, React 17.0.1. Not 18 yet.

La matrice de la 1.23.2 est claire : Node v22, TypeScript jusqu'à 5.8, React 17.0.1. SPFx ne prend pas encore en charge React 18 : cela figure toujours dans la feuille de route. Épingler n'est pas de la bureaucratie : c'est ce qui sépare un build reproductible d'un build qui se dérobe sous les pieds entre une machine et le pipeline.

Et la 1.24 ?

La 1.24 est en préversion, en bêta depuis le 8 juillet 2026, et elle apporte la nouveauté qui montre où va SPFx : les SharePoint Copilot Apps. Ce sont des composants SPFx, avec le même empaquetage et le même outillage, mais qui s'affichent dans le canvas de Microsoft 365 Copilot plutôt que dans une page SharePoint. Un composant Copilot étend BaseCopilotComponent, et non BaseClientSideWebPart, et un même .sppkg peut réunir les deux.

C'est une véritable préversion, et Microsoft l'assume : elle ne s'affiche que dans le canvas Copilot, elle ne se distribue pas par le Store, et le nom lui-même peut changer avant la version finale. C'est bon pour le laboratoire, dans un tenant de développement, pas pour la production. Le signal qui compte, c'est la direction prise : SPFx cesse d'être réservé à SharePoint pour devenir le moyen de placer sa propre interface dans Copilot.

Ce qui reste

La 1.23.2 est la bonne version pour de nouveaux projets en production, mais on ne la traite pas comme un simple changement de numéro. Le runtime de SharePoint tient ; ce qui casse, c'est la chaîne de build, les imports Sass, les personnalisations Gulp qui disparaissent en 1.24, et des fonctionnalités dont le rollout côté serveur n'est pas encore terminé. Mettre à jour SPFx, c'est une migration de build déguisée en bump. Épinglez les versions, testez le build, et menez la migration vers Heft avec un plan, pas avec un npm install.