複数パッケージのリポジトリを、今の動きを壊さずに変更する

## 直す前に、変更を受け持つパッケージと決まりを確かめる 編集前に、リポジトリのルート、対象の振る舞いを所有するパッケージまたはサブシステム、最も近くで適用される貢献者向け指示を特定する。 - 作業は、正しく適用できる最小の範囲へ振り分ける。 - その範囲に必要なローカルのアーキテクチャ、規約、ビルド、テストの資料を読む。 - 単一シンボルには対象を絞った検索を使い、ファイルをまたぐ呼び出し元、import、名前変更の影響、広い変更範囲には利用可能な依存関係グラフを使う。 - バージョン管理下の設定から、ランタイムとパッケージマネージャーの版、ワークスペース定義、ビルド前提条件を確認する。 - リンク済みまたは生成済みの指示ファイルは、宣言された正本を表示するものとして扱い、正本だけを編集する。 指示が競合する場合や所有範囲が不明な場合は、書き込む前に止まり、競合内容を正確に示す。調査中に無関係なパッケージを変更しない。 ## 今の動きと公開名を残し、今のアーキテクチャに合わせる 既存利用者の動作を壊さない。承認済みの変更で明示的に必要とされない限り、既定値を変えたり公開名を廃止したりしない。従来名を動作させたままにし、非推奨化には文書化された移行手順と従来動作のテストを組み合わせる。 リポジトリですでに確立されたアーキテクチャを尊重する。 - 振る舞いを、それを所有する層または拡張境界の内側に保つ。 - 中核契約が変わる場合は、公式アダプター間の機能同等性を維持する。 - 段階的な設定方式と公開カスタマイズ契約を保つ。 - 利用者が制御する内容を無害化し、グローバル名前空間を汚染しない。 - 宣言された国際化とアクセシビリティの要件に対応する。 - 並行する仕組みを増やすより、既存ユーティリティと最小限の依存関係を優先する。 互換性を壊す変更が避けられない場合は、目立つ形で明示し、影響を受ける契約を説明して移行経路を示す。 ## 変更は最小にし、テストと文書を一緒に足す 要件を満たす、最小で一貫した変更を行う。パッケージで確立されたコード、コメント、文書の書式に従う。 振る舞いを変更する場合は、次を行う。 1. 対象を絞った単体テストを追加または更新する。 2. 振る舞いが境界をまたぐ場合は、適切な統合テスト、ブラウザテスト、エンドツーエンドテストを追加する。 3. 依存先パッケージのテスト前に、必要な前提ビルドを実行する。 4. 影響範囲に絞って、lint、型、スタイル、テストの各コマンドを実行する。 5. 利用者から見える変更では、公開ガイド、APIリファレンス、例、移行注記、変更履歴を更新する。 6. 永続的な規約、場所、制約、繰り返し発生する注意点が新たに生じる場合にだけ、その範囲の貢献者向け指示を更新する。 必要なテスト範囲や利用者向け文書が欠けている状態で完了を主張しない。実行できなかったテストと、その具体的な理由を記録する。 ## 依存関係を足す前に許可を取り、リリース前に確かめる 第三者依存関係を追加する前に、保守担当者の承認を得る。直接および推移的ライセンス、保守状況、セキュリティ上の影響、バンドルまたは実行時のコスト、リポジトリ内に同等機能がすでにあるかを確認する。 リポジトリのブランチ、プルリクエスト、レビュー、変更履歴の規約に従う。変更履歴をレビュー可能な状態に保ち、共有履歴を書き換えず、無関係な作業を分ける。複数日にわたる作業では、リポジトリで承認された共同作業方法を使って、確認できる中間地点を残す。 リリース前に、互換性テストが新旧両方の動作を対象としていること、必要な文書があること、生成済み成果物が最新であること、対象のパッケージ構成またはアダプターを実際に確認したことを確かめる。 ## 実行したテストと、まだ残るリスクを報告する 次の項目を含む簡潔な検証レポートを返す。 - 変更した振る舞いとその範囲。 - 影響を受けたファイルまたはコンポーネント。 - 実行したテスト、ビルド、lint、型チェックとその結果。 - 互換性とセキュリティに関する考慮事項。 - 文書または変更履歴の更新。 - 未実行の項目、残存リスク、次に必要な対応。 検証済みの結果と仮定を分ける。互換性を壊す変更や未完了の必須確認は、副次的な詳細より先に強調する。