Konteks dan prompt
Sebuah monorepo TypeScript berukuran besar sedang bermigrasi dari 5.9 ke 6.0 dan kemudian mengevaluasi jalur native-compiler. Tim mengamati bahwa memindahkan deklarasi yang tidak terkait dapat mengubah urutan union dalam file .d.ts yang dihasilkan, dan beberapa error inferensi muncul atau menghilang. Jelaskan mengapa --stableTypeOrdering ada, mengapa flag ini bukan flag optimasi permanen, dan bagaimana cara mengisolasi cacat tipe yang sebenarnya tanpa memperluas risiko upgrade.
Catatan rilis TypeScript 6.0 mendeskripsikan opsi ini sebagai alat bantu migrasi yang membuat perilaku pengurutan lebih mendekati 7.0, namun berpotensi memperlambat pemeriksaan tipe hingga sekitar 25%. Opsi ini tidak ditujukan sebagai default jangka panjang; ketika opsi ini mengungkap sebuah perbedaan, prioritaskan argumen tipe atau anotasi eksplisit dan pertahankan build kontrol yang dapat direproduksi.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin melihat apakah Anda memahami hubungan antara emisi deklarasi dan ID tipe, serta apakah Anda dapat memisahkan gangguan pengurutan (ordering noise) dari error tipe yang sebenarnya. Jawaban yang kuat mencakup referensi proyek, cache inkremental, artefak yang dihasilkan, baseline performa, rollback CI, dan penguncian versi kompilator.
Pertanyaan klarifikasi awal
- Apakah perubahan tersebut terjadi pada output
.d.ts, tampilan editor, atau error assignability yang sebenarnya? - Apakah proyek menggunakan referensi proyek, build inkremental, atau pembuatan kode?
- Apakah kompilator 6.0 dan target 7.0,
tsconfig, serta dependensi telah dikunci? - Berapa batas waktu (budget) pemeriksaan tipe, dan paket mana yang memperbesar biaya tersebut?
- Apakah upgrade yang gagal dapat kembali ke 5.9 atau menonaktifkan flag diagnostik?
Jawaban 30 detik
"Saya akan memperlakukan --stableTypeOrdering sebagai alat diagnostik migrasi 6-ke-7, bukan sakelar performa permanen. ID tipe pada TypeScript 6.0 bergantung pada urutan pemrosesan deklarasi, sehingga pengeditan yang tidak terkait dapat mengubah output union atau mengekspos inferensi yang rapuh. Saya akan membandingkan build yang terkunci dengan dan tanpa flag tersebut pada output .d.ts, error, dan durasi; menambahkan argumen tipe atau anotasi eksplisit untuk kontrak yang sebenarnya; serta membatasi mode yang lebih lambat ini hanya pada proyek yang terdampak. Jika performa atau generator mengalami regresi, saya akan mempertahankan opsi rollback ke 5.9."
Pembahasan mendalam langkah demi langkah
1. Kunci kompilator dan input
Kunci TypeScript, Node, manajer paket, tsconfig, dependensi, dan generator. Jalankan commit yang sama dengan 5.9, default 6.0, 6.0 --stableTypeOrdering, dan toolchain target 7.0. Simpan data error, hash deklarasi, durasi pemeriksaan, dan data cache-hit.
2. Jelaskan sumber pergeseran urutan
Kompilator menetapkan ID yang sensitif terhadap urutan ke tipe-tipe dan menggunakannya untuk mengurutkan union dan output deklarasi. Menambahkan literal yang tidak terkait dapat mengubah ID tersebut, mengubah 100 | 500 menjadi 500 | 100 dalam sebuah .d.ts. Urutan itu sendiri bukanlah perubahan runtime, tetapi kode yang mengandalkan inferensi yang rapuh dapat mengalami perubahan diagnostik.
export function choose(flag: boolean) {
return flag ? 100 : 500;
}
// An unrelated declaration may change literal-union ordering in the declaration file.
const unrelated = 500;Jangan memperlakukan urutan teks deklarasi sebagai bukti semantik; periksa assignability konsumen, inferensi argumen tipe, dan kompatibilitas API.
3. Gunakan stableTypeOrdering dengan benar
Flag ini membuat pengurutan 6.0 lebih mendekati 7.0 untuk mengungkap perbedaan lintas-versi. Hal ini dapat menambah hingga sekitar 25% pada waktu pemeriksaan, jadi aktifkan hanya pada branch migrasi, proyek yang terdampak, atau job diagnostik. Catat cakupannya alih-alih memperlambat seluruh CI tanpa tindakan yang jelas.
4. Ubah inferensi implisit menjadi kontrak eksplisit
Jika flag tersebut mengungkap panggilan yang bergantung pada urutan pemrosesan, tambahkan argumen tipe eksplisit, anotasi variabel, tipe kembalian publik, atau batasan generik. Periksa kembali .d.ts, referensi proyek, dan konsumen downstream sehingga perbaikan tersebut memperkuat kontrak alih-alih hanya mengubah urutan.
5. Verifikasi emisi dan jalur inkremental
Ulangi proses build dengan referensi proyek, declaration, generator, language service, dan cache inkremental. Jalankan sekali dari cache yang bersih untuk membedakan masalah pengurutan dari kontaminasi cache. Periksa artefak yang dihasilkan untuk stabilitas, tetapi jangan jadikan teks deklarasi yang diformat sebagai satu-satunya oracle pengujian.
6. Tetapkan gerbang migrasi dan rollback
Gunakan matriks build bersyarat untuk membandingkan jumlah error, API deklarasi, durasi pemeriksaan, dan diff paket. Lakukan ekspansi hanya jika hasil 6.0 dan target 7.0 dapat dijelaskan, API publik tidak berubah, dan performa tetap sesuai anggaran. Pada regresi yang serius, nonaktifkan flag, kembali ke 5.9 atau pengurutan default, dan simpan bukti tingkat commit.
Jawaban model
Saya akan mengunci input dan membangun matriks empat arah: 5.9, 6.0 default, 6.0 --stableTypeOrdering, dan toolchain target 7.0. Opsi ini membuat pengurutan 6.0 lebih mendekati 7.0 untuk diagnosis migrasi, tetapi dapat memperlambat pemeriksaan dan tidak boleh diterapkan secara global selamanya. Saya akan membandingkan .d.ts, error konsumen yang sebenarnya, referensi proyek, generator, dan perilaku cache, lalu menambahkan argumen tipe atau anotasi eksplisit di mana inferensi bergantung pada urutan. Saya akan melanjutkan proses hanya setelah gerbang API, performa, dan rollback terlewati.
Kesalahan umum
- Memperlakukan perubahan urutan union sebagai perubahan runtime → membingungkan representasi deklarasi dengan eksekusi → verifikasi tipe konsumen dan kompatibilitas API.
- Membiarkan
--stableTypeOrderingaktif selamanya → dapat menambah sekitar 25% waktu pemeriksaan → batasi cakupannya hanya untuk diagnostik migrasi. - Hanya membandingkan tampilan editor → melewatkan emisi deklarasi dan build downstream → audit
.d.ts, referensi, dan paket. - Mengubah urutan hanya demi membuat CI berwarna hijau → menyembunyikan inferensi yang rapuh → tambahkan kontrak eksplisit dan simpan hasil kontrol.
- Tidak ada rollback ke 5.9 → kegagalan upgrade menjadi sulit diisolasi → kunci versi dan pertahankan build bersyarat.
Pertanyaan lanjutan
Mengapa deklarasi yang tidak terkait dapat mengubah urutan union?
TypeScript mengurutkan menggunakan ID tipe yang ditetapkan selama pemrosesan, sehingga deklarasi yang tidak terkait dapat mengubah ID tersebut. Hasilnya biasanya berupa perbedaan output deklarasi, tetapi hal itu dapat mengekspos kode yang mengandalkan urutan inferensi.
Haruskah flag ini selalu diaktifkan?
Tidak. Dokumentasi memposisikannya sebagai alat bantu diagnostik dari 6.0 ke 7.0 yang dapat memperlambat pemeriksaan secara signifikan. Kembalikan ke pengaturan normal setelah diagnosis migrasi selesai.
Bagaimana Anda membedakan error nyata dari gangguan pengurutan?
Dengan input yang terkunci, bandingkan error, .d.ts, assignability downstream, dan kontrak tipe di bawah pengurutan default dan stabil. Perbaiki hanya kontrak konsumen atau API publik yang rusak, bukan sekadar penataan ulang teks yang tidak berbahaya.
Mengapa lebih memilih argumen tipe eksplisit?
Argumen tersebut mencatat niat secara jelas dalam kode sumber, menghilangkan dependensi implisit pada urutan pemrosesan, dan membuat 6.0, 7.0, serta editor lebih berpeluang untuk sepakat.
Kapan diagnostik migrasi dapat diakhiri?
Ketika hasil toolchain target dapat dijelaskan, API deklarasi stabil, jalur emisi dan inkremental lolos pengujian, performa sesuai anggaran, dan bukti rollback tersedia, nonaktifkan flag diagnostik dan lanjutkan dengan upgrade.