Ein öffentliches Serverpaket ändern, ohne Code zu brechen, der es erweitert

## Prüfen, was öffentlich ausgeliefert wird, und Geheimnisse fernhalten Ermitteln Sie vor der Bearbeitung das Veröffentlichungsziel, die Lizenz, das Modulsystem, die Programmiersprache, die Laufzeitrolle und den Synchronisationspfad des Pakets. Behandeln Sie jede Datei in einem öffentlich synchronisierten Paket als Inhalt der öffentlichen Veröffentlichung, selbst wenn die Entwicklung in einem privaten Arbeitsbereich erfolgt. - Legen Sie niemals Geheimnisse, lizenzbeschränktes Verhalten oder ausschließlich interne Testvorrichtungen im öffentlichen Paket ab. - Halten Sie reine Serverpakete frei von Benutzeroberflächen; führen Sie keine Browser- oder DOM-Abhängigkeiten ein. - Richten Sie sich nach den tatsächlich verwendeten Modul- und Sprachkonventionen des Pakets, anstatt Muster benachbarter Pakete zu übernehmen. - Erfassen Sie die direkten abhängigen Komponenten im Arbeitsbereich und gehen Sie davon aus, dass weitere externe Paketverbraucher vorhanden sind. Die öffentliche Verteilung vergrößert den Auswirkungsradius auch dann, wenn im Arbeitsbereich nur eine abhängige Komponente sichtbar ist. ## Alte Callback-Formen und tiefe Importpfade funktionsfähig halten Stellen Sie Rückruffunktionen nicht stillschweigend auf Promises oder asynchrone Funktionen um. In Code aus unterschiedlichen Entwicklungsphasen kann ein Erweiterungshook von der Form der Rückruffunktion abhängen, selbst wenn benachbarte Aufrufstellen synchron oder Promise-basiert sind. Vor der Änderung eines Aufrufs: 1. Erfassen Sie jede Implementierung des Erweiterungspunkts. 2. Vergleichen Sie Argumentreihenfolge, Rückgabeverhalten, Zeitpunkt der Rückruffunktion und Fehlersemantik. 3. Halten Sie sich an den Stil der geänderten Datei. 4. Ergänzen oder aktualisieren Sie Tests für jede unterstützte Aufrufform. Benennen oder verschieben Sie intern wirkende Hilfs-, Middleware- oder Modelldateien erst, nachdem nachgelagerte Repositorys nach Tiefenimporten durchsucht wurden. Ein Import über einen Quellpfad ist eine implizite öffentliche API und kann ohne Compilerwarnung brechen. ## Middleware-Reihenfolge und Hook-Namen genau einhalten Bewahren Sie Middleware-Abhängigkeiten ausdrücklich. Authentifizierung oder Token-Auflösung müssen vor Berechtigungsprüfungen ausgeführt werden, wenn die Autorisierung auf den befüllten Benutzerkontext zugreift. Behandeln Sie Reihenfolgeänderungen als Vertragsänderungen und nicht als Formatbereinigung. Übernehmen Sie für neue Middleware die im Paket etablierte Erzeugerform, etwa eine paketbezogene Erzeugerfunktion, die einen Anfragebearbeiter zurückgibt, und registrieren Sie sie an der vorgesehenen Stelle der zentralen Kette. Verwenden Sie den vorhandenen Änderungshook-Mechanismus als Erweiterungsschnittstelle. Suchen Sie vor dem Hinzufügen einer Aufrufstelle nach allen aktuellen Hook-Namen und Implementierungen. Bestätigen Sie den genauen Namen, den Eingabewert, die Rückruf- oder Rückgabeform und das Standardverhalten; ein falsch geschriebener Hook kann unbemerkt den Standardwert zurückgeben. Dokumentieren Sie jeden neuen Erweiterungspunkt an einer Stelle, an der nachgelagerte Implementierer ihn finden können. ## Neue Migrationen ergänzen, statt ausgelieferte zu ändern Folgen Sie den etablierten Basisabstraktionen, anstatt parallele Muster zu erfinden. Neue Datenmodelle sollten das gemeinsame Modellmodul oder die Basisform verwenden. Neue REST-Ressourcen auf oberster Ebene sollten die gemeinsame Ressourcenbasis erweitern und ihre Routen über den zentralen Einstiegspunkt registrieren. Behandeln Sie ausgelieferte Datenbankmigrationen als unveränderlich und einseitig: - Bearbeiten Sie eine bestehende Migration nach der Veröffentlichung niemals. - Fügen Sie für jede spätere Korrektur eine neue nummerierte Migration hinzu. - Gestalten Sie jede Migration idempotent. - Berücksichtigen Sie Unterbrechungen und wiederholte Ausführungen beim Start. - Prüfen Sie das Verhalten sowohl mit neuen als auch mit bereits migrierten Datenbanken. Wenn nachgelagerte Pakete Modellfelder oder Verhalten über Hooks einfügen, prüfen Sie diese Einfügestellen, bevor Sie Schemas, Standardwerte, Serialisierung oder Hydratisierung ändern. ## Betroffene andere Pakete finden und beide Seiten testen Ordnen Sie eine Änderung vor der Umsetzung ihren Verbrauchern zu. Stimmen Sie sich mit nachgelagerten Aufrufern ab, wenn Sie Authentifizierungs-Middleware, Berechtigungsverarbeitung, Sitzungsgrenzen, gemeinsame Hilfsprogramme, Verschlüsselungshilfen, Modell-Hooks oder Signaturen von Erweiterungspunkten ändern. Behandeln Sie über Tiefenimporte eingebundene Hilfsprogramme als öffentliche APIs. Behandeln Sie die Zuständigkeit für Token gegenüber Sitzungen als Architekturgrenze. Wenn ein Wert als Verweis gespeichert und beim Lesen hydratisiert wird, prüfen Sie sowohl die schreibende Seite als auch den Verweisauflöser, bevor Sie seine Darstellung ändern. Für jede bereichsübergreifende Änderung: 1. Lesen Sie die einschlägigen Hinweise zu Architektur, Abhängigkeiten und bekannten Fallstricken. 2. Suchen Sie nachgelagerte Implementierungen und Aufrufstellen. 3. Benennen Sie den Vertrag, der weiterhin gelten muss. 4. Testen Sie beide Seiten der Grenze. 5. Dokumentieren Sie jede beabsichtigte Vertragsänderung und ihren Migrationspfad. ## Werte testen, die die Grenze der VM-Sandbox überqueren Änderungen an VM-Bündeln, Kompatibilitätsschichten, Auswerterinstanzen, Ressourcengrenzen oder Fehlersemantik erfordern eine vollständige Prüfung des Client-Server-Vertrags. Halten Sie die Kompatibilitätsschichten von Host und abgeschotteter Umgebung gleichwertig, erstellen Sie das Bündel neu und prüfen Sie, dass Werte die Laufzeitgrenze unversehrt überqueren. Gehen Sie nicht davon aus, dass aktive Datenbankobjekte nach der Serialisierung durch eine isolierte Laufzeit ihre Identität oder Prototypen behalten. Testen Sie Kennungen, Verweise, Datumswerte, Puffer, Fehler und hydratisierte Werte in beiden Richtungen. Achten Sie auf prozessweite Änderungen des Hostzustands durch Kompatibilitätsschichten, die beim Laden eines Moduls initialisiert werden. Ein nachgebildeter Browserkontext kann einen globalen Zustand erzeugen, selbst wenn das Paket ohne Benutzeroberfläche bleiben soll. Behandeln Sie von der Abdeckungsmessung ausgeschlossenen Bündelcode als bekannte Testlücke und ergänzen Sie gezielte Ausführungsprüfungen, anstatt anzunehmen, die gewöhnliche Abdeckung beweise seine Korrektheit. ## Datenbankfunktionen beim Start prüfen und einen Ausweichweg bereithalten Unterstützen Sie mehrere Datenbankimplementierungen, indem Sie deren Fähigkeiten beim Start prüfen. Schalten Sie erweiterte Sortierregeln, Suchpipelines, zusammengesetzte Indizes für verschachtelte Pfade und andere über die Grundausstattung hinausgehende Funktionen nur entsprechend dem Prüfergebnis frei und liefern Sie eine getestete Ausweichlösung mit. Leiten Sie Kompatibilität niemals aus einem Produktnamen oder einer Versionszeichenfolge ab, wenn die Laufzeit eine Fähigkeitsübersicht bereitstellt. Wiederholt zurückgenommene Änderungen belegen, dass der Prüf- und Ausweichpfad Teil des Vertrags ist. Wenn das Verhalten des öffentlichen Pakets von einem Funktionsschalter abhängt, das Paket das private Register aber nicht importieren kann, rufen Sie den etablierten Erweiterungshook mit der genauen Schlüsselzeichenfolge des Schalters auf. Prüfen Sie den Schlüssel gegen das Register und testen Sie sowohl den aktivierten als auch den deaktivierten Pfad. Betten Sie keine Logik des privaten Registers in das öffentliche Paket ein. ## Die Tests, Lint und Builds ausführen, die das Paket wirklich hat Definieren Sie „erfolgreich“ anhand der Skripte, die das Paket tatsächlich bereitstellt. Bei einem reinen JavaScript-Paket kann dies die vollständige Testsammlung und das Prüfprogramm bedeuten, ohne einen nicht vorhandenen Typprüfungsschritt zu erfinden. Führen Sie die Bündelerstellung aus, wenn sich die Änderung auf die gebündelte Laufzeitausgabe auswirkt. Registrieren Sie jede neue Testdatei im zentralen Importmodul der Testsammlung, wenn sie nicht automatisch gefunden wird; eine nicht registrierte Testdatei bietet keinen Schutz. Verwenden Sie den unterstützten Testnamensfilter, um die Untersuchung einzugrenzen, führen Sie vor Abschluss jedoch die gesamte erforderliche Testsammlung aus. Gehen Sie vorsichtig mit automatisch korrigierenden Prüfkommandos um und prüfen Sie deren Änderungsübersicht. Bestätigen Sie, dass Tests, Codeprüfung und die maßgebliche Bündelerstellung erfolgreich sind, und bewahren Sie Warnungen, die Laufzeit- oder Kompatibilitätsprobleme sichtbar machen. ## Vor dem Abschluss die gesamte Auswirkung bestätigen Beginnen Sie beim betroffenen Vertrag und nicht bei der nächstgelegenen Datei. Suchen Sie nach bekannten Fallstricken und nachgelagerten Abhängigkeiten, nehmen Sie die kleinste kompatible Änderung vor und prüfen Sie vor der Abschlussmeldung die Sicherheit der öffentlichen Veröffentlichung. Die abschließende Begutachtung muss bestätigen: - Keine geheimen, zugangsbeschränkten oder ausschließlich internen Inhalte gelangten in das öffentliche Paket. - Verträge für Rückruffunktionen, Hooks, Tiefenimporte und Middleware-Reihenfolge gelten weiterhin. - Migrationen sind ergänzend und idempotent. - Grenzen für Modelle, Verweise, virtuelle Maschinen und Datenbankfähigkeiten wurden bei Betroffenheit getestet. - Neue Tests sind registriert und die tatsächlichen Qualitätsprüfungen des Pakets sind erfolgreich. - Paketübergreifende Aufrufer und die Dokumentation wurden an den erforderlichen Stellen aktualisiert. - Eine inkompatible Änderung oder Änderung für eine neue Hauptversion ist mit allen Veröffentlichungszielen abgestimmt. Bezeichnen Sie eine Änderung nicht allein deshalb als isoliert, weil die Anzahl der Abhängigkeiten im Arbeitsbereich klein ist; öffentliche Verbraucher bleiben Teil des Risikomodells.