Lompat ke konten
Kembali ke modul

TypeScript: Menangkap Kesalahan Sebelum Sampai Produksi · 8/8

tsconfig, strict mode, dan proses build

Arti opsi-opsi compiler, dan kenapa type hilang sama sekali saat runtime.

Baca 25 menit

Setelah pelajaran ini kamu bisa

  • Menjelaskan apa yang terjadi pada type saat kode di-build
  • Menyebutkan fungsi opsi-opsi penting di tsconfig
  • Menjelaskan apa yang sebenarnya dinyalakan oleh `strict`
  • Menjelaskan kenapa type-checking dan build itu dua langkah terpisah

Fakta terpenting soal TypeScript: type-nya dihapus. Yang berjalan adalah JavaScript biasa dengan semua anotasi dibuang. Tidak ada apa pun dari type-mu yang ada saat runtime.

ts
// What you write:
interface Venue {
  id: number;
  name: string;
}

function describe(venue: Venue): string {
  const label: string = venue.name;
  return label.toUpperCase();
}

// What actually runs, after the types are erased:
function describe(venue) {
  const label = venue.name;
  return label.toUpperCase();
}
// The interface produced no code at all. It existed only to be checked.
Coba sendiri

Akibatnya: kamu tidak bisa menanyakan sebuah type saat runtime, karena tidak ada yang bisa ditanya.

Hasil

Tekan Jalankan untuk melihat hasilnya.

Ini jalan di browser kamu, di dalam sandbox. Apa pun yang kamu tulis di sini tidak bisa merusak situs.

tsconfig.json

tsconfig.json mengonfigurasi checker-nya. File di proyek ini layak dibaca — ini opsi-opsi yang penting.

OpsiApa yang diaturnya
strictMenyalakan semua pemeriksaan ketat sekaligus. Selalu biarkan menyala.
targetVersi JavaScript yang dihasilkan. Proyek ini memakai ES2022.
libAPI bawaan apa yang dianggap ada, misalnya type DOM
module / moduleResolutionCara import ditemukan dan dihasilkan
noEmitHanya memeriksa, tidak menghasilkan file — Next.js yang membangunnya
pathsAlias import, misalnya @/* di proyek ini
jsxCara JSX dikompilasi
skipLibCheckJangan type-check dependency. Biasanya jawabannya ya, demi kepraktisan.

Apa yang sebenarnya dinyalakan strict

strict: true itu sebuah paket. Dua yang paling mengubah pekerjaan harianmu:

ts
// strictNullChecks - the big one.
// OFF: null and undefined are assignable to everything, and you get
//      "cannot read properties of undefined" in production instead.
// ON:  the compiler forces you to handle absence.
function greet(name: string | undefined) {
  return "Hi " + name.toUpperCase();
  //                ~~~~ 'name' is possibly 'undefined'
}

// noImplicitAny - a parameter with no annotation is an error, not a silent any.
function double(n) {
  //            ~ Parameter 'n' implicitly has an 'any' type.
  return n * 2;
}
Tanpa strictNullChecks, TypeScript menangkap jauh lebih sedikit dari yang diperkirakan orang. Ini opsi yang memberikan sebagian besar manfaatnya.

Memeriksa bukan membangun

Ini dua pekerjaan terpisah, dan alat modern memisahkannya. Checker (tsc) membaca type-mu dan melaporkan error. Builder (Turbopack, esbuild, Bun) membuang type-nya dan menghasilkan JavaScript, dan jauh lebih cepat karena ia tidak memeriksa apa pun.

bash
bunx tsc --noEmit     # check types, write nothing
bun run build         # build for production (Next.js also runs the check)
node scratch.ts       # Node 24 strips the types and runs it - no check at all
Yang terakhir layak diingat: node scratch.ts tetap jalan meski file-nya penuh type error. Membuang type bukan berarti memeriksanya.

Tugas praktik

Di scratch.ts, sengaja tulis const n: number = "hello";. Jalankan bunx tsc --noEmit dan lihat error-nya. Sekarang jalankan node scratch.ts dan lihat ia tetap dieksekusi, mencetak sebuah string dari variable yang dianotasi sebagai number. Lalu buka tsconfig.json di proyek ini dan temukan strict, target, dan paths, lalu cocokkan masing-masing dengan tabel di atas.

Hasil yang diharapkan

tsc melaporkan error; node menjalankan file-nya tanpa masalah dan mencetak "hello".

Cek pemahaman

node scratch.ts menjalankan file yang berisi const n: number = "hello". Kenapa ia tidak gagal?

Pilih jawaban dulu