bharath2020/expo-navigations-migration

Migration der Expo-Navigation (SDK 58)

Drei Aufgaben. Je nach Anfrage auswählen; ein Migrationsplan benötigt alle drei in der richtigen Reihenfolge.

Anfrage	Vorgehen
„Wie wird die Navigation in diesem Repository gehandhabt?“	Analysieren
„Plane die Migration“, „Können wir das flaggen?“, „React Navigation oder @expo/ui?“	Analysieren, dann Planen
„Wir verwenden React Navigation und möchten mehr native Elemente sowie eine stabile Bibliothek für Navigation und Deep Links“	Analysieren, dann Planen, mit dem Szenario für bestehendes React Navigation
„Wie erstelle ich ein Sidebar-/Sheet-/Duo-Layout?“, „Funktioniert X?“	Im Katalog nachschlagen

Durchgängig verwendete Zielnamen:

• React Navigation bedeutet Expo Router auf react-native-screens. Seit SDK 56 hängt expo-router nicht mehr von @react-navigation/* ab und forkt die Teile, auf denen es aufbaut. SDK 58 hat den Großteil dieser geforkten API entfernt.
• Plain React Navigation bedeutet @react-navigation/* 7.x ohne Expo Router.
• @expo/ui bedeutet SwiftUI auf iOS und Jetpack Compose auf Android.

Lies nur das Ziel-Repository. Diese Skill plant; sie ändert keinen Anwendungscode, es sei denn, der Benutzer fordert dies separat an.

Expo ändert sich mit jedem SDK. Die hier genannten API-Fakten wurden am 02.11.2026 für SDK 58 geprüft. Rufe https://docs.expo.dev/versions/v58.0.0/ für jede API auf, auf die du dich verlassen möchtest und die der Katalog nicht als verifiziert ausweist.

Analysieren

1. Führe node <skill>/scripts/inventory-navigation.mjs <repo-root> aus. Das Skript liest nur und gibt Signale mit path:line-Positionen aus. Wenn ein Signal truncated größer Null anzeigt, führe es erneut mit --max-locations 200 aus.
2. Folge references/analysis.md. Fülle templates/analysis-report.md.

Abgeschlossen, wenn jede Zeile des Berichts einen Wert mit Beleg enthält oder angibt, wonach gesucht und nichts gefunden wurde, und jedes Inventarsignal durch Lesen des Codes bestätigt oder verworfen wurde.

Planen

Folge references/migration-planning.md. Dies greift zu auf:

• references/target-decision.md: die Empfehlung zwischen den Zielen
• references/flag-seams.md: wo ein Flag sitzen kann, was dokumentiert ist, was einen Spike benötigt
• references/no-flag-paths.md: der Wechsel, wenn kein Flag möglich ist
• references/api-mapping.md: SDK-Sprünge, Import-Ersetzungen, Breaking Changes
• references/existing-react-navigation.md: das Szenario für Archetyp N oder den N-Teil von M: Startpunkt, Stabilitätsreihenfolge, Deep Links

Fülle templates/migration-plan.md. Der Plan deckt immer Folgendes ab: den geflaggten Wechsel, den Wechsel ohne Flag, geordnete Schritte, die jeweils allein ausgeliefert und verifiziert werden, sowie einen sauberen Ausstieg, der das Flag und alles, was der Plan ersetzt hat, entfernt. Er benennt eine Empfehlung mit Begründung aus diesem Repository. Diese Empfehlung kann auch lauten, den aktuellen Besitzer der Navigation zu behalten; wenn nur das SDK wechselt, sagt der Plan, dass es nichts zu flaggen gibt, und warum.

Muster nachschlagen

references/pattern-catalog.md listet jedes Szenario und seine Datei auf. Jede Datei enthält Code aus einem funktionierenden Prototyp für beide Ziele auf iOS und Android, Status pro Plattform, Stolperfallen und Migrationshinweise. Zitiere Statuswörter wie geschrieben: verifiziert bedeutet auf einem Simulator oder Emulator getestet; es wurde keine physische Hardware verwendet.

templates/ enthält die wiederverwendbaren Dateien: die lokalen Module für Sidebar-Abschnitte, Sidebar-Platzierung und Navigationsleisten-Sichtbarkeit, die Navigations-Hilfsschicht sowie die Hinge- und Pane-Split-Komponenten. Lokale Module benötigen einen Development Build.