‍

Upgrades

Wie du eine neue Flow-Version einspielst – der Migrationsleitfaden für Breaking Changes, die Codemod-CLI und was direkt nach einem Release zu beachten ist.

Migration bei einer Breaking Change

Jede Änderung, die eine Anpassung in deinem Code erfordert, steht mit Vorher-Nachher-Beispiel im Migrationsleitfaden des betroffenen Packages:

Die Einträge sind nach Version absteigend sortiert und nennen jeweils die Version, ab der die Änderung greift. Suche die Version, von der du kommst, und arbeite dich nach oben durch. Was dabei überhaupt als Breaking Change zählt und eine neue Major-Version erzwingt, beschreibt Versionierung & Stabilität‍.

Nutze die Codemod-CLI

Ein Befehl hebt alle Flow-Abhängigkeiten auf die Zielversion, installiert und führt den Codemod jeder Migration bis zu dieser Version aus:

Ohne Argument geht es auf die nächste Minor innerhalb deiner Major. upgrade patch bleibt auf deiner Minor, upgrade major überquert eine Major-Grenze, und eine exakte Version oder ein Dist-Tag (next) gehen genau dorthin.

Der Befehl ändert Dateien direkt und bricht auf einem unsauberen Git-Stand ab.

Der Befehl kennt keine untere Grenze: er listet auch Migrationen, die vor deiner aktuellen Version erschienen sind. Nichts hält fest, welche davon dein Projekt schon durchgeführt hat – und ein zweiter Durchlauf eines Codemods ändert nichts.

Er ersetzt den Migrationsleitfaden nicht: die meisten Einträge haben keinen Codemod. Welche das für deinen Bereich sind, listet der Befehl am Ende auf – oder vorab, ohne etwas zu verändern, mit list und derselben Revision:

list ohne Argument zeigt den gesamten Katalog, offline. Mit einer Revision liest es dieselbe Version aus deinem package.json und zeigt genau den Bereich, den upgrade mit dieser Revision anfassen würde – ein echter Trockenlauf.

Einen einzelnen Codemod führst du über seine ID aus:

Deprecation-Warnungen sind der Vorlauf

Wird ein Pfad deprecated, bleibt er funktionsfähig und meldet sich zur Laufzeit per console.warn. Diese Warnungen sind die Vorwarnzeit vor der nächsten Major-Version – behandle sie als Aufgabenliste, nicht als Rauschen. Um sie zentral einzusammeln, etwa im Error-Tracking, umschließe deine Anwendung mit einem DeprecationWarningProvider und gib ihm einen onWarning-Handler:

Direkt nach einem Release

Ein Release veröffentlicht die Packages nacheinander, nicht gleichzeitig. Für einige Minuten liegt in der npm-Registry deshalb für die schon veröffentlichten Packages die neue Version, für die restlichen noch die alte. Beim Release 1.0.6 lagen zwischen dem ersten und dem letzten Package rund 25 Minuten.

Du triffst dieses Fenster leicht, denn ein Update betrifft immer mehrere Packages: alle @mittwald/flow-*-Packages teilen sich eine gemeinsame Version, und @mittwald/flow-react-components fordert @mittwald/flow-icons-pro als Peer-Dependency in exakt derselben Version. Ziehst du in diesem Fenster alle Flow-Abhängigkeiten auf die neue Version, schlägt die Installation für das Package fehl, das noch nicht dran war:

pnpm meldet dasselbe als ERR_PNPM_NO_MATCHING_VERSION.

Das ist keine Lücke im Release: sobald der Release-Lauf durch ist, haben alle Packages dieselbe Version. Direkt nach einem Release ist dieser Fehler fast immer das Veröffentlichungsfenster und nichts anderes.

Auf dieser Seite