Wawancara Koding: Bagaimana Cara Melakukan Migrasi yang Aman ke Kompiler Native TypeScript 7?

Perintah dan konteks

Tim Anda mengelola aplikasi web dan paket bersama dalam monorepo TypeScript 6. Type-checking CI terlalu lambat, dan repositori tersebut menggunakan typescript-eslint, sebuah webpack loader, serta perkakas template Vue dan Angular. Anda harus mengevaluasi kompiler native TypeScript 7.

Rancang rencana migrasi yang mempertahankan lapisan kompatibilitas TypeScript 6, menjadwalkan peningkatan CLI dan editor, mengendalikan risiko memori dari pemeriksaan paralel, serta menentukan gate canary, metrik, dan rollback.

Hal yang diuji oleh pewawancara

• Apakah Anda membedakan antara dependensi CLI tsc, language service editor, dan API programatik TypeScript.
• Apakah versi yang dipin, dua kompiler, dan artefak yang sebanding dapat mengurangi risiko migrasi.
• Apakah paralelisme, memori, perbedaan diagnostik, dan kompatibilitas ekosistem menjadi release gate yang dapat dieksekusi.
• Apakah Anda dapat menyatakan batasan yang ditimbulkan oleh ketiadaan API programatik yang stabil pada TypeScript 7 saat ini.

Pertanyaan untuk klarifikasi

1. Apakah CI menggunakan tsc --build, proyek terisolasi, atau API kompiler kustom?
2. Perkakas mana yang mengimpor typescript secara langsung, dan mana yang hanya membaca deklarasi atau output CLI?
3. Apakah stableTypeOrdering pada TypeScript 6 diaktifkan, dengan baseline untuk deklarasi, diagnostik, dan waktu build?
4. Apakah versi editor, batas memori Node, dan CPU/memori CI runner sudah ditetapkan (fixed)?

Jawaban 30 detik

Saya akan menginventarisasi setiap konsumen API TypeScript, lalu menginstal CLI TypeScript 7 berdampingan dengan paket kompatibilitas TypeScript 6 dengan versi yang dipin dan sebuah lockfile. Di CI, saya akan membandingkan deklarasi, diagnostik, JavaScript yang dihasilkan, source map, pengujian, dan penggunaan sumber daya; saya akan mengaktifkan stableTypeOrdering di sisi TypeScript 6 terlebih dahulu. Saya akan meningkatkan --checkers dan --builders TypeScript 7 hanya dari sebuah baseline, sambil mempertahankan --singleThreaded sebagai sakelar diagnostik. Perkakas Vue, MDX, Astro, Svelte, dan Angular tanpa jalur API yang stabil akan tetap berada di TypeScript 6. Saya akan menggunakan canary, peluncuran editor bertahap, dan rollback berversi eksplisit sebelum memperluas adopsi.

Pembahasan mendalam langkah demi langkah

Inventarisasi dependensi kompiler dan API

Catat versi Node, package manager, TypeScript, tsconfig, project reference, loader, plugin, dan editor. Klasifikasikan konsumen sebagai CLI, deklarasi/artefak yang dihasilkan, language service, atau API programatik; pengguna API programatik memerlukan pemeriksaan kompatibilitas terpisah.

Instal TypeScript 7 dan TypeScript 6 secara berdampingan

Saat ini TypeScript 7 menyediakan kompiler native tetapi belum memiliki API yang stabil. Biarkan tsc menggunakan 7 sementara alias npm mempertahankan tsc6:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Pin versi yang lolos validasi dan lakukan commit pada lockfile. Skrip harus memanggil setiap biner secara eksplisit agar perataan package-manager tidak secara diam-diam memilih kompiler yang salah.

Tetapkan baseline artefak yang sebanding

Aktifkan stableTypeOrdering TypeScript 6 terlebih dahulu, kemudian simpan .d.ts, diagnostik, JavaScript yang dihasilkan, source map, cache inkremental, dan hasil pengujian. Pisahkan perubahan urutan, kesalahan tipe yang sebenarnya, dan perbedaan pemformatan alat; hanya perubahan yang dapat dijelaskan dan aman untuk API yang masuk ke dalam allowlist.

Sesuaikan paralelisme checker dan builder

TypeScript 7 menggunakan empat worker checker secara default, dan builder juga dapat berjalan secara paralel. Lakukan pengukuran pada CPU, memori, dan urutan proyek yang tetap sebelum meningkatkan paralelisme. Catat wall-clock time, puncak RSS, GC, dan percobaan ulang (retries); lakukan rollback jika anggaran memori runner terlampaui. Gunakan --singleThreaded untuk mereproduksi nondeterminisme dan pertahankan jumlah worker yang tetap di CI.

Isolasi perkakas ekosistem dan peluncuran editor

Jangan memaksa perkakas template untuk ditingkatkan sebelum API programatik yang stabil tersedia. Perkakas Vue, MDX, Astro, Svelte, dan Angular mungkin masih bergantung pada API TypeScript 6, jadi biarkan perkakas tersebut menggunakan tsc6 atau pertahankan language service TS6 terpisah. Aktifkan ekstensi editor yang cocok untuk saluran pengembang kecil terlebih dahulu dan amati tingkat penyelesaian (completion), navigasi, diagnostik, serta crash.

Canary, metrik, dan rollback

Mulai dengan paket berisiko rendah dan satu canary CI. Bandingkan waktu build, perbedaan diagnostik, kompatibilitas deklarasi, puncak memori, kesalahan editor, dan tingkat kelulusan pengujian. Jika terjadi kegagalan, pulihkan lockfile lama, skrip, dan saluran editor TS6; hanya menghapus paket TS7 dapat meninggalkan loader yang tidak cocok. Perluas ke workspace lain hanya setelah semua gate lolos berulang kali.

Jawaban model

Nilai utama dari TypeScript 7 adalah kompiler native dan CLI yang lebih cepat, tetapi konsumen API menentukan batasan migrasi. Saya akan menjalankan rencana dua jalur: TS7 untuk pekerjaan CLI dan TS6 untuk kompatibilitas. Pin kedua versi, ekspos tsc dan tsc6, serta arahkan loader, perkakas template, dan editor sesuai dengan dependensi API programatiknya. Pertama, aktifkan stableTypeOrdering dan bandingkan deklarasi, diagnostik, artefak yang dihasilkan, source map, pengujian, dan penggunaan sumber daya. Sesuaikan pengaturan paralel terhadap runner yang tetap, menggunakan --singleThreaded untuk reproduksi. Perluas melalui canary dan adopsi editor bertahap; regresi diagnostik apa pun, kerusakan deklarasi, kelebihan memori, atau kegagalan editor akan memicu rollback. Karena TypeScript 7 belum memiliki API programatik yang stabil, pertahankan TS6 hingga perkakas ekosistem menyelesaikan validasinya.

Kesalahan umum

• Mengganti versi typescript tanpa memeriksa loader, plugin, dan perkakas template yang mengimpor API-nya.
• Mengaitkan setiap peningkatan kecepatan dengan kompiler native tanpa baseline repositori atau anggaran memori.
• Memperlakukan perubahan urutan deklarasi sebagai regresi tipe tanpa mengaktifkan stableTypeOrdering.
• Memaksimalkan paralelisme CI sambil mengabaikan memori runner dan perilaku percobaan ulang.
• Mengasumsikan kompatibilitas editor dan API programatik hanya karena CLI berjalan.
• Merencanakan rollback lisan "uninstall TS7" tanpa mempertahankan lockfile, skrip, dan versi editor.

Pertanyaan lanjutan

Jika sebuah loader bergantung pada API TypeScript 6, bisakah hanya CI yang ditingkatkan?

Ya. Tingkatkan hanya canary pemeriksaan tipe terlebih dahulu, pertahankan loader pada tsc6 atau API TypeScript 6, dan verifikasi artefak serta deklarasi yang dihasilkan sebelum meningkatkan loader.

Apakah nilai --checkers yang lebih besar selalu lebih baik?

Tidak. CPU, memori, graph proyek, dan GC semuanya berpengaruh. Pilihlah berdasarkan wall-clock time dan puncak RSS pada runner yang tetap, dan pertahankan nilai yang lebih kecil sebagai cadangan (fallback).

Kapan TypeScript 6 dapat dihapus?

Setelah setiap konsumen API programatik, perkakas template, editor, dan plugin build lulus validasi kompatibilitas serta metrik canary tetap berada di dalam batasan gate. Evaluasi kembali lapisan kompatibilitas ketika TypeScript 7 memiliki API yang stabil.

Bagaimana Anda membuktikan bahwa hasil tipe tidak berubah?

Bandingkan diagnostik, deklarasi, JavaScript yang dihasilkan, source map, dan pengujian, sambil mengklasifikasikan perbedaan urutan dan pemformatan. Kesamaan pada exit-code saja tidak cukup.