Warum SharePoint Framework immer noch auf React 17 läuft
Vierzehn SPFx-Versionen später läuft SharePoint Framework immer noch auf React 17. Das ist keine Geschichte über ein altes Framework. Es ist eine Geschichte darüber, was sich bewegen muss, bevor sich eine Plattform bewegen kann.
Vierzehn aufeinanderfolgende SharePoint-Framework-Versionen sind mit React 17.0.1 erschienen. Vierzehn.
Das klingt nach Stillstand. Ist es nicht, und es wird nur selten anders besprochen.
Zuerst die Fakten
Microsoft veröffentlicht für jede SPFx-Version eine Kompatibilitätstabelle. Das sagt sie über React, geprüft am 5. August 2026 (SPFx-Kompatibilität von Plattform und Toolchain):
| Zeitraum | SPFx | React |
|---|---|---|
| Seit Februar 2017 | 1.0.0 bis 1.6.0 | 15 |
| Bis November 2022 | 1.7.0 bis 1.15.2 | 16.x |
| Seit November 2022 | 1.16.0 bis 1.23.2 | 17.0.1 |
Drei Hauptversionen von React in zehn Jahren SPFx, und die aktuelle hält seit vierzehn Versionen in Folge. Die Version, die es geändert hat, ist datiert und eindeutig: SPFx 1.16.0, veröffentlicht am 15. November 2022, "SPFx unterstützt React 17 jetzt standardmäßig" (Versionshinweise 1.16.0).
Ein Vergleich macht es schärfer. React 18 erschien im März 2022, acht Monate davor. Microsoft hat nicht die neueste Version gewählt und ist dann zurückgefallen. Microsoft hat eine Version ausgeliefert, die am Tag ihres Erscheinens bereits eine Generation alt war.
Was auch immer das ist, eine Wette auf Neuheit war es nie.
Wir wissen, was ein React-Hauptversionswechsel kostet, weil es bereits passiert ist
Die naheliegende Frage ist, warum es so lange dauert. Die Antwort steht in den Versionshinweisen des letzten Mals.
SPFx 1.16.0 ist die Version, die SharePoint von React 16 auf React 17 gebracht hat. Während dieses Übergangs behob Microsoft unter anderem:
- Listenerweiterungen, die wegen einer React-Versionsabweichung ausfielen (#8482)
- Invalid-Hook-Call-Fehler in Webparts (#8487)
- den Eigenschaftenbereich, der nicht angezeigt wurde (#8496)
- einen minimierten React-Fehler, die #321 (#8510)
Das sind Microsofts eigene Versionshinweise. Keine Forenbeschwerde, keine Anekdote.
Ein einziger React-Hauptversionswechsel hat Kundencode in der Produktion beschädigt, und die Korrekturen erschienen zusammen mit der Änderung, die sie verursacht hatte.
Der Satz, der die Geschichte verändert
Die SPFx-Roadmap listet datierte Versionen bis September 2026. React 18 steht in keiner davon. Es steht in einem eigenen Abschnitt namens Top of Mind, ohne Version und ohne Datum, mit diesem Text (SPFx-Roadmap, geprüft am 5. August 2026):
"React-18-Unterstützung für SPFx-Lösungen. Dieses Update hängt davon ab, dass die von Microsoft bereitgestellten Webparts und Oberflächen auf die React-18-Version aktualisiert werden. Diese Arbeit ist im Gange."
Lesen Sie die Abhängigkeit noch einmal, denn sie verläuft in die entgegengesetzte Richtung zu der, die üblicherweise angenommen wird.
Nicht die Kunden warten darauf, dass Microsoft ein Framework-Update abschließt. Microsoft kann das Framework-Update nicht anbieten, solange sich die eigenen Webparts nicht bewegt haben.
Die eigene Oberfläche von Microsoft ist der Engpass.
Jede Organisation mit einem eigenen Webpart steht stromabwärts einer internen Migration, die sie weder sieht noch beeinflusst noch planen kann.
Zusammen mit dem vorherigen Abschnitt gelesen, wird das Bild klar. Wenn der Wechsel von 16 auf 17 Listenerweiterungen, Eigenschaftenbereiche und Hooks in der Produktion beschädigt hat, sieht das fehlende Datum für 17 auf 18 nicht mehr nach Nachlässigkeit aus, sondern nach einer zutreffenden Schätzung.
Hier geht es nicht um npm
Von außen sieht das nach einem Abhängigkeits-Update aus. Ist es nicht.
Was in dem Moment, in dem React sich ändert, tatsächlich zusammenhalten muss:
- Microsofts eigene Webparts, die auf Hunderten Millionen Seiten gerendert werden, die niemand einzeln testen wird;
- Fluent UI, das SPFx-Projekte seit 1.18 in v8 verwenden (Fluent UI in SPFx verwenden);
- jede jemals ausgelieferte Kundenlösung, gebaut gegen einen Laufzeitvertrag, der zum Zeitpunkt ihrer Entstehung galt;
- die Laufzeitumgebung selbst, in der Microsofts Code und Ihrer eine Seite und eine React-Instanz teilen.
Der letzte Punkt ist das ganze Problem. Eine SharePoint-Seite ist keine Anwendung mit einem Eigentümer. Sie ist eine geteilte Laufzeitumgebung, in der Microsofts Code und Ihrer nebeneinander laufen, und eine Hauptversion von React ist kein privates Implementierungsdetail, wenn beide Hälften sich darauf einigen müssen.
React 17 ist in SharePoint nicht mehr nur eine Framework-Version. Es ist zu einer Plattformabhängigkeit geworden. Plattformabhängigkeiten bewegen sich nicht, wenn eine Partei bereit ist. Sie bewegen sich, wenn alle Parteien es sind.
Warum das außerhalb von Microsoft für Sie zählt
Alles oben Genannte beschreibt Microsofts Herausforderung. Dieser Teil ist Ihrer.
Die Einschränkung bleibt nicht innerhalb der Plattform. Sie landet in Ihrem Repository, in der Version, die Sie installieren, und in dem, was Ihr Webpart auf einer Seite tut, die Sie nicht kontrollieren.
Die Fehlerart ist Stille
Die Kompatibilitätsseite von Microsoft enthält diese Warnung:
"Die Verwendung inkompatibler React-Versionen kann zu stillen Laufzeitfehlern ohne klare Fehlermeldungen während des Buildvorgangs führen."
Und sie empfiehlt, die Version exakt festzuschreiben:
npm install react@17.0.1 react-dom@17.0.1 --save-exact
Still ist das entscheidende Wort. Eine gegen React 18 gebaute Lösung kompiliert. Sie läuft lokal. Sie besteht das Review. Und dann rendert sie in der Produktion eine leere Fläche, ohne dass die Konsole etwas dazu sagt.
Es gibt keinen Fehler zu suchen, weil es keinen Fehler gibt. Wenn Sie eine einzige Anweisung aus diesem Artikel mitnehmen: schreiben Sie die React-Version, die Ihre SPFx-Version vorgibt, exakt fest und prüfen Sie das im Review. Nicht weil ein neueres React schlechter wäre, sondern weil die Laufzeitumgebung, in die Sie ausliefern, bereits entschieden hat.
Was KI hier ändert, und das ist weniger als gedacht
Ein Agent schreibt Ihr Webpart in Sekunden. Er schreibt das JSX, die Eigenschaften, die Hooks und die Tests, und er macht es gut.
Nichts davon ist die Einschränkung. Die Einschränkung ist, dass eine Seite Microsoft-Code und Fremdcode in eine Laufzeitumgebung laden muss und beide funktionieren müssen. Keine Menge generierten Codes macht ein Ökosystem mit sich selbst kompatibel, denn Kompatibilität ist kein Problem des Codeschreibens. Sie ist eine Übereinkunft zwischen Parteien, die nach unterschiedlichen Zeitplänen ausliefern, und eine davon hat Hunderte Millionen Nutzer, die nie etwas vereinbart haben.
KI schreibt Komponenten. Plattformen müssen sich weiterhin über die Laufzeitumgebung einigen.
Was wir nicht wissen
Uns ist ein ausdrückliches "wir wissen es nicht" lieber als eine selbstsichere Vermutung, die in sechs Monaten falsch sein wird.
- Wann React 18 kommt. Microsoft sagt, die Arbeit sei im Gange, und nennt kein Datum. Zum Zeitpunkt der Veröffentlichung verknüpft die offizielle SharePoint-Framework-Roadmap die React-18-Unterstützung mit keiner veröffentlichten oder geplanten SPFx-Version.
- Ob der nächste Schritt überhaupt React 18 ist. React hat sich seit 17 weiterentwickelt. Eine Version zu überspringen ist eine legitime Strategie, und Microsoft hat sich in keine Richtung geäußert. Die interessante Frage ist nicht, was React als Nächstes veröffentlicht hat, sondern was sich ändern muss, bevor SharePoint Framework mitgehen kann.
- Wie viel von Microsoft 365 bereits migriert ist. "Im Gange" ist die gesamte öffentliche Information.
Die Frage darunter
Die Frage war nie, warum Microsoft immer noch React 17 verwendet.
Microsofts Problem ist nicht, React zu aktualisieren. Microsofts Problem ist, ein Ökosystem zu aktualisieren: eine eigene Oberfläche, eine Komponentenbibliothek, eine geteilte Laufzeitumgebung und jede Lösung, die je ein Kunde ausgeliefert hat, und alle müssen sich am selben Tag einig sein.
Viele Organisationen stellen fest, dass sie genau dasselbe Problem haben. Die Abhängigkeit ist eine andere, die Laufzeitumgebung ist kleiner und das Publikum misst sich in Tausenden statt in Hunderten Millionen, aber die Form ist identisch. Etwas Grundlegendes muss sich ändern, und die Antwort auf "was würde dadurch kaputtgehen" steht nirgends geschrieben.
Wenn eine Organisation mit Microsofts Mitteln dafür mehr als vier Jahre braucht, lohnt sich die Frage, was sich bewegen müsste und wer zustimmen müsste, bevor Sie in Ihrem eigenen Bestand eine grundlegende Abhängigkeit ändern könnten.
Die meisten Organisationen haben es nie gezählt. Das ist gewöhnlich die Antwort.
Warum dieser Artikel altern sollte. Wir erwarten, dass SharePoint Framework irgendwann eine neuere React-Version unterstützt. Wenn das geschieht, handelt dieser Artikel nicht mehr von React 17 und weiterhin von etwas anderem: davon, warum sich Plattformabhängigkeiten langsamer bewegen als Abhängigkeiten einer Anwendung, und warum das eine Eigenschaft der Plattform ist und kein Versagen derer, die sie pflegen.
Wenn Ihnen diese Art technischer Analyse nützt: der SharePoint Migration Field Guide folgt demselben Ansatz. Erst die Entscheidungen, dann die Dokumentation, Marketing nie. Auf Englisch verfasst.
