プロンプトとコンテキスト
大規模なTypeScriptモノレポが5.9から6.0への移行を進めており、その後ネイティブコンパイラへの移行パスを評価しています。チームは、無関係な宣言を移動させると出力される.d.tsファイル内のユニオン型の順序が変化し、一部の推論エラーが出現または消失することを観察しています。--stableTypeOrderingが存在する理由、それが恒久的な最適化フラグではない理由、およびアップグレードリスクを拡大させずに本物の型の不具合を切り分ける方法を説明してください。
TypeScript 6.0のリリースノートでは、このオプションは型の順序付け動作を7.0により近づける移行支援機能として説明されていますが、型チェックが最大で約25%低下する可能性があります。これは長期的なデフォルトとして意図されたものではありません。差異が明らかになった場合は、明示的な型引数やアノテーションを優先し、再現可能な対照ビルドを保持してください。
面接官がテストしていること
面接官は、あなたが宣言の出力と型IDの関係を理解しているか、そして順序付けのノイズと本物の型エラーを区別できるかを確認しようとしています。優れた回答では、プロジェクト参照、インクリメンタルキャッシュ、生成されたアーティファクト、パフォーマンスベースライン、CIロールバック、および固定されたコンパイラバージョンがカバーされます。
最初に明確にすべき質問
- 変更は
.d.ts出力、エディタ表示、または実際の代入可能性エラーのいずれで発生しましたか？ - プロジェクトはプロジェクト参照、インクリメンタルビルド、またはコード生成を使用していますか？
- 6.0および移行対象の7.0コンパイラ、
tsconfig、および依存関係はロックされていますか？ - 型チェックの許容時間バジェットはどのくらいで、どのパッケージがコストを増大させていますか？
- アップグレードに失敗した場合、5.9に戻すか、または診断フラグを無効化できますか？
30秒の回答
「私は--stableTypeOrderingを恒久的なパフォーマンススイッチではなく、6から7への移行診断として扱います。TypeScript 6.0の型IDは宣言の処理順序に依存するため、無関係な編集がユニオンの出力を変更したり、脆弱な推論を露呈させたりすることがあります。フラグの有無によるロックされたビルドを.d.ts出力、エラー、実行時間全体で比較し、実際のコントラクトに対して明示的な型引数やアノテーションを追加し、低速なモードは影響を受けるプロジェクトに限定します。パフォーマンスやジェネレータが退行した場合は、5.9へのロールバックを維持します。」
ステップバイステップの詳細解説
1. コンパイラと入力を固定する
TypeScript、Node、パッケージマネージャ、tsconfig、依存関係、およびジェネレータをロックします。同一のコミットに対して、5.9、6.0デフォルト、6.0 --stableTypeOrdering、および対象の7.0ツールチェーンを実行します。エラー、宣言ハッシュ、チェック所要時間、およびキャッシュヒットデータを保存します。
2. 順序の変動の原因を説明する
コンパイラは型に順序依存のIDを割り当て、それらを使用してユニオン型や宣言出力を整列します。無関係なリテラルを追加するとIDが変化し、.d.ts内で100 | 500が500 | 100に変わる可能性があります。順序自体はランタイムの変更ではありませんが、脆弱な推論に依存していたコードでは診断結果の変化として現れることがあります。
export function choose(flag: boolean) {
return flag ? 100 : 500;
}
// An unrelated declaration may change literal-union ordering in the declaration file.
const unrelated = 500;宣言テキストの順序を意味論的な証明として扱わないでください。利用側の代入可能性、型引数の推論、およびAPIの互換性を検証してください。
3. stableTypeOrderingを正しく使用する
このフラグは6.0の順序付けを7.0に近づけ、バージョン間の差異を浮き彫りにします。チェック時間が最大で約25%増加する可能性があるため、移行ブランチ、影響を受けるプロジェクト、または診断ジョブでのみ有効にしてください。具体的なアクションなしにCI全体を遅くするのではなく、適用範囲を限定して記録します。
4. 暗黙の推論を明示的なコントラクトへ変換する
フラグによって処理順序に依存していた呼び出しが露呈した場合は、明示的な型引数、変数のアノテーション、公開戻り値の型、またはジェネリック制約を追加します。単に順序を変更するのではなく修正によってコントラクトが強化されるよう、.d.ts、プロジェクト参照、および下流の利用側を再確認します。
5. 出力とインクリメンタルパスを検証する
プロジェクト参照、declaration、ジェネレータ、ランゲージサービス、およびインクリメンタルキャッシュを使用してビルドを再実行します。クリーンなキャッシュから一度実行して、順序の問題とキャッシュ汚染を区別します。生成されたアーティファクトの安定性を確認しますが、フォーマットされた宣言テキストのみをテストのオラクル（判定基準）にしないでください。
6. 移行およびロールバックのゲートを設定する
条件付きビルドマトリクスを使用して、エラー数、宣言API、チェック所要時間、およびパッケージ差分を比較します。6.0と対象7.0の結果が説明可能であり、公開APIが変更されておらず、パフォーマンスがバジェット内に収まっている場合にのみ展開を進めます。重大なリグレッションが発生した場合は、フラグを無効化し、5.9またはデフォルトの順序に戻し、コミットレベルのエビデンスを保持します。
模範解答
入力をロックし、5.9、6.0デフォルト、6.0 --stableTypeOrdering、および対象の7.0ツールチェーンの4通りのマトリクスを構築します。このオプションは移行診断のために6.0の順序付けを7.0に近づけますが、チェックを遅くする可能性があり、恒久的に全体へ適用すべきではありません。.d.ts、実際の利用側エラー、プロジェクト参照、ジェネレータ、およびキャッシュの挙動を比較し、推論が順序に依存していた箇所には明示的な型引数やアノテーションを追加します。API、パフォーマンス、およびロールバックのゲートを通過した後にのみ移行を継続します。
よくある間違い
- ユニオン順序の変更を実行時の変更として扱う → 宣言の表現と実行を混同している → 利用側の型とAPIの互換性を検証する。
--stableTypeOrderingを恒久的に有効にしたままにする → チェック時間が約25%増加する可能性がある → 移行診断のスコープに限定する。- エディタ表示のみを比較する → 宣言出力や下流のビルドを見落とす →
.d.ts、参照、パッケージを監査する。 - CIをグリーンにするためだけに順序を変更する → 脆弱な推論を隠蔽してしまう → 明示的なコントラクトを追加し、対照結果を保持する。
- 5.9へのロールバックがない → アップグレード失敗の原因特定が困難になる → バージョンを固定し、条件付きビルドを維持する。
フォローアップ質問
なぜ無関係な宣言がユニオンの順序を変更することがあるのですか？
TypeScriptは処理中に割り当てられた型IDを使用してソートするため、無関係な宣言がそれらのIDを変更する可能性があります。その結果は通常、宣言出力の差異にとどまりますが、推論順序に依存していたコードが露呈することもあります。
このフラグは常に有効にしておくべきですか？
いいえ。ドキュメントではこれを6.0から7.0への診断支援機能と位置づけており、チェックを大幅に遅くする可能性があります。移行診断の後は通常の設定に戻してください。
本物のエラーと順序のノイズをどのように区別しますか？
入力をロックした上で、デフォルトの順序と安定した順序の下で、エラー、.d.ts、下流の代入可能性、および型コントラクトを比較します。無害なテキスト上の並び替えではなく、壊れた利用側コントラクトや公開APIのみを修正します。
なぜ明示的な型引数を優先するのですか？
ソースコードに意図を明確に記録し、処理順序への暗黙の依存関係を排除することで、6.0、7.0、およびエディタ間で結果が一致する可能性が高まるためです。
移行診断はいつ終了できますか？
対象ツールチェーンの結果が説明可能であり、宣言APIが安定し、出力およびインクリメンタルパスがパスし、パフォーマンスがバジェットに適合し、ロールバックのエビデンスが存在する場合、診断フラグを無効にしてアップグレードを進めることができます。