Die Microsoft Build 2026 hat für SharePoint-Entwickler mehr Neuigkeiten gebracht als die vergangenen drei Konferenzen zusammen. Das SharePoint Framework (SPFx) bekommt React 18, ein komplett neues Build-System, eine eigene CLI und eine verbindliche quartalsweise Release-Kadenz. Dieser Artikel fasst zusammen, was sich ändert, was Migrationsbedarf entsteht und wie Schweizer Entwicklungsteams am besten vorgehen.

React 18 im SharePoint Framework

Der meisterwartete Schritt: SPFx unterstützt ab der für Juni 2026 angekündigten Version offiziell React 18. Damit werden Concurrent Features – insbesondere startTransition, useDeferredValue und das neue Suspense-Rendering-Modell – in SPFx-Web-Parts nutzbar.

Wichtiger Vorbehalt: Microsoft hat explizit kommuniziert, dass Out-of-the-Box-Web-Parts (also die mitgelieferten SharePoint-Standard-Web-Parts) zuerst auf React 18 aktualisiert werden müssen, bevor das Framework die React-Version im gesamten Tenant verbindlich auf 18 anhebt. Bis dahin wird React 18 im SPFx-Kontext als opt-in betrieben: Neue Projekte können React 18 bereits verwenden, aber Lösungen, die in Tenants laufen, in denen noch nicht alle OOB-Web-Parts aktualisiert sind, müssen mit Kompatibilitätsproblemen rechnen.

Was React 18 konkret bringt

• Concurrent Rendering: UI-Updates können unterbrochen und priorisiert werden – wichtig für komplexe SharePoint-Dashboards mit vielen Datenquellen
• Automatisches Batching: Mehrere setState-Aufrufe in Promises, Timeouts und nativen Events werden jetzt automatisch gebatcht
• Suspense für Data Fetching: Datenladevorgänge können direkt im JSX-Baum deklariert werden
• useId-Hook: Stabile, serverseitig-sichere IDs – relevant für barrierefreie Formulare und ARIA-Attribute in Web-Parts
• useDeferredValue und startTransition: Flüssigere Filterung und Suche in List-Web-Parts ohne Jank

Migrationspfad von React 17 auf React 18

Bestehende SPFx-Lösungen, die mit ReactDOM.render() arbeiten, müssen auf createRoot() aus react-dom/client umgestellt werden:

// Vorher (React 17 / SPFx bis 1.19)
import ReactDOM from 'react-dom';
ReactDOM.render(<MyWebPart {...props} />, this.domElement);

// Nachher (React 18 / SPFx 1.20+)
import { createRoot } from 'react-dom/client';
const root = createRoot(this.domElement);
root.render(<MyWebPart {...props} />);

In WebPart.ts muss das Root-Objekt persistiert und bei onDispose() explizit mit root.unmount() abgebaut werden. Wer das vergisst, erzeugt Memory Leaks bei der Navigation zwischen Seiten.

Gulp durch Heft und webpack ersetzt

Das alte Gulp-basierte Build-System hat SPFx-Entwickler seit Jahren gebremst: langsame Builds, schwer zu debuggende Pipeline-Schritte und kaum Erweiterbarkeit. Mit Build 2026 macht Microsoft den Wechsel zu Heft (dem Rush-Stack Build-Orchestrator von Microsoft) und webpack 5 offiziell und standardmässig.

Warum Heft?

Heft ist der Build-Orchestrator, den Microsoft intern für Office und Teams verwendet. Er ist für grosse Monorepos ausgelegt, läuft Tasks parallel und hat ein sauberes Plugin-Modell. Wichtige Vorteile gegenüber Gulp:

Migrationsvorgehen

1. 1SPFx CLI nutzen (siehe nächster Abschnitt) – das neue spfx upgrade-Kommando aktualisiert package.json, entfernt Gulp-Abhängigkeiten und generiert heft.json und webpack.config.js
2. 2gulpfile.js löschen – nach dem Upgrade nicht benötigt; Heft übernimmt alle Tasks
3. 3Custom Gulp-Tasks portieren – benutzerdefinierte Schritte müssen als Heft-Plugins neu geschrieben werden. Einfache Tasks wie SCSS-Kompilierung sind oft bereits als Heft-Standard-Plugins verfügbar
4. 4CI/CD anpassen – Pipeline-Scripts, die gulp bundle --ship oder gulp package-solution --ship aufrufen, müssen auf heft build --production umgestellt werden

Wichtig für bestehende Projekte: Microsoft stellt einen automatisierten Migrationspfad bereit; Lösungen mit sehr spezifischen Gulp-Anpassungen (z. B. Custom Localization-Pipelines oder SVG-Sprite-Generierung) erfordern manuelle Portierung.

Die neue SPFx CLI – Yeoman adé

Yeoman war als Scaffolding-Tool ein Fremdkörper im modernen JavaScript-Ökosystem: schwerfällig, mit vielen globalen npm-Abhängigkeiten und kaum wartbar. Microsoft ersetzt Yeoman durch eine eigene, Open-Source SPFx CLI, die als npm-Paket installiert wird:

npm install -g @microsoft/spfx-cli

Neue Kommandos

# Neues Projekt scaffolden
spfx new --template web-part --name MyDashboard

# Bestehendes Projekt auf aktuelle SPFx-Version upgraden
spfx upgrade

# Solution packen (entspricht gulp bundle + gulp package-solution --ship)
spfx build --production

# Direkt in SharePoint deployen (ohne manuelle .sppkg-Upload)
spfx deploy --site https://contoso.sharepoint.com/sites/dev

# Dev-Server starten (ersetzt gulp serve)
spfx serve

Die CLI ist unter github.com/microsoft/spfx-cli open-source und nimmt Community-Contributions an. Für Schweizer Entwicklungsteams, die eigene Scaffolding-Templates pflegen, bietet die neue CLI erheblich einfachere Erweiterungsmöglichkeiten als das alte Yeoman-Generator-Modell.

Quartalsweise Release-Kadenz

Microsoft hat mit Build 2026 erstmals eine verbindliche vierteljährliche Release-Kadenz für SPFx angekündigt:

• Q1 (Januar): Stabilitäts- und Security-Release
• Q2 (April / Mai): Feature-Release mit Vorschau-Features aus der Dev-Community
• Q3 (Juli): Mid-year-Release mit Bugfixes und Performance-Updates
• Q4 (Oktober / November): Major Feature-Release (wie React 18 dieses Jahr)

Das bedeutet für Teams: SPFx-Versionssprünge alle drei Monate statt unregelmässiger Ad-hoc-Releases. Die Upgrade-Skripte sollen entsprechend nach jeder Quartals-Release aktualisiert werden. Für Unternehmen mit längeren Freigabeprozessen empfiehlt es sich, Upgrades in der Q1- und Q3-Version einzuplanen (Stabilitäts-Releases) und Q2/Q4 zunächst in einer Dev-Tenant-Umgebung zu testen.

Navigation Customizers

Ebenfalls in der Build-2026-Ankündigung: Application Customizer können jetzt auf Navigation Customizers erweitert werden – eine lang ersehnte Funktion. Navigation Customizers erlauben es, die SharePoint-Hauptnavigation, die Hub-Navigation und die Footer-Navigation vollständig durch eigene React-Komponenten zu ersetzen, ohne SPFx-Tenantoverrides oder PnP-Hacks.

Anwendungsfälle

• Unternehmensweite, markengerechte Navigation ohne SharePoint-Standard-UI
• Dynamische Navigation basierend auf Entra-ID-Gruppen (z. B. unterschiedliche Menüs für HR, IT und Management)
• Integration von Such- und KI-Assistenten direkt in die Navigation (z. B. Microsoft Copilot-Sidebar)
• Mehrsprachige Navigation für Schweizer Unternehmen mit DE/FR/IT-Anforderungen

// Minimal-Beispiel Navigation Customizer
import { BaseApplicationCustomizer, PlaceholderName } from '@microsoft/sp-application-base';
import { createRoot } from 'react-dom/client';

export default class NavCustomizerApplicationCustomizer extends BaseApplicationCustomizer {
  public onInit(): Promise<void> {
    const topNav = this.context.placeholderProvider.tryCreateContent(
      PlaceholderName.Top
    );
    if (topNav) {
      const root = createRoot(topNav.domElement);
      root.render(<CompanyNavigation context={this.context} />);
    }
    return Promise.resolve();
  }
}

Migrations-Checkliste für Schweizer Entwicklungsteams

Sofort (vor dem Tenant-Upgrade auf SPFx 1.20)

• SPFx CLI installieren: npm install -g @microsoft/spfx-cli
• Alle bestehenden Lösungen mit spfx upgrade --dry-run analysieren
• Dev-Tenant auf SPFx 1.20 upgraden und Lösungen testen

Kurzfristig (nächste 4–8 Wochen)

• ReactDOM.render() auf createRoot() in allen Web-Parts migrieren
• onDispose() in allen Web-Parts auf root.unmount() aktualisieren
• Gulp-Pipeline durch Heft ersetzen (spfx upgrade führt den Grossteil automatisch durch)
• CI/CD von gulp bundle --ship auf heft build --production umstellen
• Benutzerdefinierte Gulp-Tasks als Heft-Plugins portieren

Mittelfristig (Q3 2026)

• Concurrent-Rendering-Optimierungen (startTransition, useDeferredValue) in datenintensiven Web-Parts evaluieren
• Navigation Customizers für unternehmensweite Nav einführen
• Scaffolding-Templates von Yeoman auf SPFx CLI migrieren

Fazit

Build 2026 macht SPFx zu einem erstklassigen, modernen Entwicklungs-Framework: React 18, ein professionelles Build-System und eine eigene CLI sind Schritte, die viele Entwickler seit Jahren gefordert haben. Die quartalsweise Kadenz gibt Planungssicherheit.

Für Schweizer Entwicklungsteams gilt: Jetzt ist der richtige Zeitpunkt, die bestehende SPFx-Lösung zu inventarisieren, die Migrations-Checkliste abzuarbeiten und mit einem Dev-Tenant-Test zu beginnen – bevor Microsoft den Rollout des Q4-Updates auf Produktiv-Tenants startet.

CNEXT begleitet SharePoint-Entwicklungsprojekte in der Schweiz – von der Solution-Architektur bis zur Migration auf aktuelle SPFx-Versionen.