Ein großes typisiertes Monorepository ändern, ohne andere Pakete zu beschädigen

## Vor dem Ändern das zuständige Paket finden Beginne im Repository-Stammverzeichnis und ermittle das Paket, das für das angeforderte Verhalten zuständig ist. - Unterscheide Kernbibliotheken, Framework-Integrationen, bereitstellbare Anwendungen, Beispiele und interne Werkzeuge. - Lies den Leitfaden im Stammverzeichnis und den nächstgelegenen paketbezogenen Leitfaden; für das Verhalten des Pakets gilt der jeweils konkretere Leitfaden. - Bestätige vor dem Ausführen von Entwicklungsbefehlen die festgelegte Laufzeitversion, die Paketverwaltung, den Aufbau des Arbeitsbereichs und den erforderlichen vorbereitenden Bau. - Gehe nicht davon aus, dass im Stammverzeichnis ein Entwicklungsserver vorhanden ist. Starte das zuständige Paket oder verwende den Arbeitsbereichsfilter, der dessen vorgelagerte Abhängigkeiten einschließt. - Verfolge gemeinsam genutzte Typen, Hilfsfunktionen, Stile und erzeugte Ressourcen bis zu ihrem maßgeblichen Paket zurück, bevor du einen Verwender änderst. - Beschränke die Änderung auf das kleinste zuständige Paket, sofern sich der öffentliche Vertrag nicht tatsächlich über mehrere Pakete erstreckt. ## Build- und Abhängigkeitsregeln jedes Pakets einhalten Wähle den zum Paket passenden Erstellungspfad, statt dem gesamten Arbeitsbereich ein einziges Werkzeug aufzuzwingen. - Verwende für reine typisierte Bibliotheken einen compilerorientierten Erstellungslauf und für Oberflächenpakete einen Komponentenbündler. - Lagere Abhängigkeiten aus der Bibliotheksausgabe aus; verwende einen ausdrücklich eigenständigen Erstellungslauf nur, wenn das auszuliefernde Artefakt seine Laufzeitabhängigkeiten mit enthalten muss. - Halte interne Abhängigkeiten im Arbeitsbereichsprotokoll und beziehe gemeinsam verwendete Drittanbieterversionen aus dem zentralen Versionskatalog. - Importiere gemeinsam genutzte Typen über ihre dokumentierten Einstiegspunkte statt über ein breit gefasstes Paketstammverzeichnis. - Wenn ein Paket mehrere Formate veröffentlicht, prüfe jede deklarierte Ausgabe und die zugehörigen Typdeklarationen. - Behandle Baukonfiguration, Sperrdateien, gemeinsam genutzte Compilereinstellungen und Arbeitsbereichskataloge als Dateien mit breiten Auswirkungen, die eine umfassendere Prüfung erfordern. ## Gemeinsame Hilfsfunktionen nutzen, bevor neuer Code entsteht Durchsuche das gemeinsame Hilfsfunktionspaket, bevor du eine neue Hilfsfunktion schreibst. Prüfe vorhandene Hilfsfunktionen für Felder, Objekte, Zeichenketten, URL, HTTP, JSON, Markdown, Fehler, Dateien, Warteschlangen, Formatierung, reguläre Ausdrücke und Tests. Verwende eine passende Hilfsfunktion unmittelbar wieder. Füge dem gemeinsamen Paket nur dann eine neue Hilfsfunktion hinzu, wenn kein vorhandenes Verhalten passt und mehrere Verwender die neue Abstraktion nutzen können. Erstelle keine nahezu gleichen Umsetzungen in Funktionspaketen. Wenn ein vorhandenes Verhalten ähnlich, aber nicht genau passend ist, vergleiche Verträge, Randfälle, Auswirkungen auf die Bündelung und Aufrufstellen, bevor du entscheidest, ob du es erweiterst oder eine lokale, fachgebietsspezifische Funktion beibehältst. ## Auf `any` verzichten und Funktionen sowie Komponenten-Props typisieren Schreibe Code, der die Typableitung nützlich hält und zugleich öffentliche Verträge ausdrücklich macht. - Bevorzuge Typaliase und Vereinigungstypen aus Zeichenkettenliteralen gegenüber Schnittstellen und Aufzählungen, wenn dies dem Standard der Codebasis entspricht. - Gib Funktionen ausdrückliche Rückgabetypen, verwende `unknown` statt `any`, kennzeichne reine Typimporte und bevorzuge unveränderliche Bindungen. - Halte Importe direkt; vermeide Sammeldateien mit Ausnahme bewusst eingerichteter Paketeinstiegspunkte und vermeide Wiederausfuhren mit Platzhaltern. - Unterdrücke Typfehler niemals pauschal. Verwende eine Anweisung für einen erwarteten Fehler nur zusammen mit einem Grund, der belegt, dass der Fehler beabsichtigt ist. - Behandle jedes Promise und kennzeichne eine Funktion nur dann als asynchron, wenn sie auf Arbeit wartet. - Typisiere in Komponentendateien Eigenschaften und Ereignisse, lege Standardwerte bei der Destrukturierung fest, verschiebe nichttriviale Vorlagenlogik in berechnete Werte und befolge die festgelegte Einrichtungsreihenfolge. - Erläutere in Kommentaren und API-Dokumentation, warum eine Einschränkung besteht, statt den Code zu wiederholen. ## Zuerst das betroffene Paket testen, nicht das ganze Repository Führe den kleinsten Testumfang aus, der die Änderung nachweist. 1. Lege Modultests neben ihrem Quellcode ab und benenne die oberste Testgruppe nach der Datei. 2. Bevorzuge Verhaltensprüfungen und reine Funktionen; beschränke Testattrappen auf das Nötigste und prüfe weder die Auszeichnungsstruktur noch Gestaltungsdetails, wenn das Nutzerverhalten den Vertrag bildet. 3. Führe das betroffene Paket einmal mit einem ausdrücklichen Pfadfilter aus. Verwende den Überwachungsmodus nur während aktiver Entwicklung. 4. Führe für geänderte Adapter Integrationstests und für betroffene Nutzerwege Ende-zu-Ende-Tests aus. 5. Starte erforderliche lokale Testdienste und warte vor dienstabhängigen Tests auf deren Bereitschaft; Modultests dürfen das echte Netzwerk nicht verwenden. 6. Führe die vollständige Monorepository-Testgruppe nur für eine bewusst angesetzte abschließende Integrationsprüfung oder eine weitreichende Änderung eines gemeinsamen Vertrags aus. Behandle bereits vorhandene, nicht zusammenhängende Fehler getrennt: Reproduziere sie außerhalb des Änderungsbereichs, melde sie als solche und stelle sie weder fälschlich als Umgebungserfolg noch als durch die Änderung verursachten Fehler dar. ## Geänderte Dateien linten und betroffene Pakete auf Typen prüfen Ermittle die Menge der geänderten Dateien und wende jedes Werkzeug nur auf die Syntax an, für die es zuständig ist. - Führe das Prüf- und Formatierungswerkzeug der typisierten Sprache für geänderte typisierte Dateien aus. - Führe das Komponentenprüfwerkzeug und das allgemeine Formatierungswerkzeug für geänderte Komponenten-, Dokumentations-, Daten-, Stil- und Konfigurationsdateien aus. - Führe für jedes betroffene Paket über das zugehörige Arbeitsbereichsskript eine Typprüfung aus. - Suche nach ungenutzten Exporten, Dateien und Abhängigkeiten, bevor du eine Prüfung eröffnest oder aktualisierst. - Verlange, dass alle einschlägigen Prüfungen für statische Analyse, Formatierung, Typen, Tests und ungenutzten Code fehlerfrei bestehen. Verwende keinen Befehl für das gesamte Repository, wenn ein Paketfilter mit weniger unzusammenhängendem Rauschen ein stärkeres Signal liefert. Erweitere die Prüfung, wenn sich grundlegende Konfigurationen ändern oder die Abhängigkeitsanalyse mehrere nachgelagerte Verwender zeigt. ## Review-Titel im Format type(scope) schreiben und ein Changeset ergänzen Verwende einen eigenen Zweig und übliche Änderungsbeschreibungen im Präsens mit einem passenden Paketbereich. - Gib Prüfungstiteln mit einer zulässigen Änderungsart die semantische Form `type(scope): subject`. - Nimm Verweise auf Vorgänge und Probleme mit dem richtigen schließenden oder nicht schließenden Schlüsselwort in die Prüfungsbeschreibung auf; verstecke erforderliche Nachverfolgungskennungen nicht in Kommentaren. - Füge einen eigenen Vorgangsabschnitt hinzu, wenn Nachverfolgungsverknüpfungen vorliegen. - Prüfe bei veröffentlichungsfähigen Änderungen an Paketen, Integrationen oder Anwendungen den Stand der Versionshinweise und füge einen Patch- oder Nebenversions-Änderungssatz hinzu, wenn die Version fortgeschrieben werden soll. Führe im gewöhnlichen Arbeitsablauf keinen Hauptversionssprung ein. - Halte vorübergehende Umgehungslösungen mit einem TODO sichtbar und erläutere die Bedingung für ihre Beseitigung. - Übertrage niemals Änderungen mit bekannten Fehlern bei statischer Analyse, Typen, Tests oder ungenutzten Exporten. ## UI-Änderungen mit Screenshots in der Prüfumgebung prüfen, in der sie sichtbar sind Erstelle die vorgelagerten Pakete und wähle anschließend die Prüfumgebung, in der das geänderte Verhalten am unmittelbarsten sichtbar ist. - Verwende den Komponentenkatalog für grundlegende Bedienelemente, die Dokumentationsoberfläche für Darstellung und Navigation und die Clientoberfläche für Bearbeitung, Authentifizierung, Anfragen und Antworten. - Prüfe weitere Oberflächen, wenn gemeinsam genutzte Komponenten, Themen, Syntaxdarstellung oder Symbole in mehrere Produkte einfließen. - Erstelle Vorher-Nachher-Bildschirmaufnahmen für geänderte Oberflächen, Aufnahmen im Nutzungskontext für neues Verhalten und eine kurze Aufzeichnung für Interaktionen. - Verwende aussagekräftige Namen für Nachweisdateien und bette die Nachweise in einen eigenen visuellen Abschnitt der Prüfungsbeschreibung ein. - Wenn eine Änderung mehrere Oberflächen oder Anordnungen betrifft, erfasse jedes wesentlich andere Ergebnis, statt eine einzige Bildschirmaufnahme als allgemeingültigen Nachweis zu behandeln. Visuelle Nachweise ergänzen automatisierte Tests; sie ersetzen weder Verhaltensprüfungen noch Barrierefreiheitsprüfungen oder Typvalidierung. ## Projektbegriffe genau verwenden und nur gelaufene Prüfungen melden Verwende das Projektglossar in Code, Dokumentation, Tests und Prüfungstexten einheitlich. Unterscheide ein Protokollformat von einer API-Beschreibung, ein Datenschema von einem Dokument, Dereferenzieren von Auflösen und Bündeln von beiden Vorgängen. Vor dem Abschluss: - prüfe den endgültigen Unterschied und bestätige, dass jede geänderte Datei zum vorgesehenen Bereich gehört; - prüfe je nach Anwendbarkeit Bau, Tests, statische Analyse, Formatierung, Typen, die Suche nach ungenutztem Code und visuelle Nachweise; - bestätige, dass Paketeinstiegspunkte, Abhängigkeitskataloge und Änderungssätze mit der Umsetzung übereinstimmen; - führe jede Prüfung auf, die nicht ausgeführt werden konnte, und bewahre ihren genauen Fehlernachweis; - behaupte kein Ergebnis für das gesamte Monorepository, wenn nur eine paketbezogene Prüfung ausgeführt wurde. Melde die betroffenen Pakete, ausgeführten Befehle, unmittelbaren Ergebnisse, verbleibenden Risiken und alle bewusst aufgeschobenen Arbeiten.