SPFx 1.23.2 : mettre à jour n'est pas changer un numéro
La version précédente a été retirée de npm pour régressions, et c'est là l'avertissement : le risque de mettre à jour SharePoint Framework n'est presque jamais dans le runtime de SharePoint, il est dans le build. Ce qui a changé dans Heft, dans Sass et dans npm audit, avec le code montrant comment c'était, comment c'est, et comment ce sera.
SharePoint Framework 1.23.2 est sortie le 30 juin 2026 comme un minor bump : elle corrige des vulnérabilités npm et quelques problèmes signalés. Ça ressemble à une mise à jour de routine, de celles qu'on fait sans réfléchir. Ça ne l'est pas.
L'indice est dans la version précédente. La 1.23.1 a été publiée puis retirée de npm pour régressions. Dans un framework mature, une version sortie de la circulation est un avertissement : le risque de mettre à jour SPFx n'est presque jamais dans le runtime de SharePoint, il est dans le build. Cet article parle de ce qui a changé, de ce qui s'est cassé, et de ce qui va encore casser, avec le code montrant comment c'était, comment c'est, et comment ce sera.
Ce qui casse, ce n'est pas SharePoint, c'est le build
Un web part SPFx tourne dans le navigateur, dans une page SharePoint, et cette partie est stable depuis des années. Ce que Microsoft bouge, et fort, 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 choses liées, mais pas la même, et c'est la seconde qui casse les builds.
D'où la règle numéro un : une mise à jour SPFx n'est pas mécanique. On ne change pas le numéro dans package.json en s'attendant à ce que ça compile, Microsoft elle-même prévient que le faire donne des échecs de build. Ce qui suit, ce sont les quatre endroits où ça mord, et quoi 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 utilise toujours webpack en dessous mais piloté par lui ; 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 devient officiellement non 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
En même temps, Yeoman est remplacé par le nouveau @microsoft/spfx-cli, encore en pré-version, avec une disponibilité générale prévue pour la 1.25, en septembre. Autrement dit : toucher aux paquets et migrer le build sont des projets séparés. On met d'abord à jour vers la 1.23.2, et on planifie la migration vers Heft à part, avec des tests.
Sass a changé sans prévenir
La régression la plus dure à attraper en 1.23 est dans Sass, et Microsoft elle-même la classe comme non documentée (issue #10854). Des imports qui marchaient en 1.22 cessent de se résoudre : le préfixe ~, les bare specifiers, et le importIncludePaths cessent de fonctionner. Un projet avec du Sass sérieux compile en 1.22 et échoue en 1.23 sans une ligne de code changée.
// 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 voie, c'est le schéma pkg: pour importer les paquets npm, et revoir tous les meta.load-css(). Il y a plus dans le même lot : les source maps SCSS pointaient vers du CSS intermédiaire au lieu du .scss d'origine (#10831), et des fichiers .scss simples généraient des types CSS Module alors que webpack les traitait comme globaux (#10832). La 1.23.2 donne cela pour corrigé, mais certains issues restent ouverts sur le tracker : teste avant de supposer que c'est résolu dans ton 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, et il reste quelques modérées dans des dépendances externes. La réaction instinctive, lancer npm audit fix --force, est la mauvaise, et Microsoft dit expressément de ne pas le faire : ça réécrit des paquets transitifs que Microsoft a testés et te 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érifie si la dépendance est seulement de développement, si elle finit dans le bundle final, et qui l'a amenée.
Épingler les versions, pas @latest
La leçon de la 1.23.1, la voici : dans une pipeline, @latest est une bombe à retardement. Si le build avait attrapé la 1.23.1 le mauvais jour, il aurait installé une version que Microsoft a fini par retirer. On épingle des versions exactes, et on installe React exactement comme la matrice l'indique, 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 fait pas encore React 18, c'est toujours dans la feuille de route. Épingler n'est pas de la bureaucratie : c'est ce qui sépare un build qui se reproduit d'un qui bouge sous les pieds entre une machine et la 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, au lieu d'une page SharePoint. Un composant Copilot étend BaseCopilotComponent, non BaseClientSideWebPart, et un seul .sppkg peut réunir les deux.
C'est une vraie 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 pour le laboratoire, dans un tenant de développement, pas pour la production. Le signal qui compte, c'est la direction : SPFx cesse d'être seulement de SharePoint et devient la manière de mettre 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 échange de numéro. Le runtime de SharePoint tient ; ce qui casse, c'est la chaîne de build, les imports Sass, les customisations Gulp qui meurent en 1.24, et des fonctionnalités dont le rollout côté serveur n'est pas encore fini. Mettre à jour SPFx est une migration de build déguisée en bump. Épingle les versions, teste le build, et fais la migration vers Heft avec un plan, pas avec un npm install.
