Menyiapkan TypeScript: Compiler, tsconfig, dan Posisinya di Toolchain

Jadi kamu memutuskan untuk mencoba TypeScript. Keputusan bagus. Tapi begitu duduk untuk benar-benar memakainya, kebanyakan orang langsung menabrak deretan istilah asing: compiler, tsc, tsconfig.json, build step, watch mode. Tidak ada yang sulit sebenarnya, asal kamu paham bagaimana semuanya saling terhubung. Masalahnya, tidak ada yang lahir langsung tahu hal-hal ini.

Artikel ini menemani kamu melewati proses penyiapan itu, pelan-pelan dan dari nol. Kita tidak akan terikat pada editor, framework, atau build tool tertentu. Tujuannya supaya kamu paham apa sebenarnya tugas tiap bagian, sehingga di proyek mana pun kamu bergabung nanti, konfigurasinya terasa masuk akal, bukan seperti sihir.

Kenapa TypeScript butuh langkah penyiapan

JavaScript biasa langsung jalan. Kamu serahkan sebuah berkas .js ke browser atau ke runtime seperti Node.js, dan berkas itu langsung dieksekusi. Tidak ada perantara.

TypeScript berbeda, dan alasannya sederhana: browser dan runtime tidak mengerti TypeScript. Mereka hanya mengerti JavaScript. TypeScript adalah lapisan yang kamu tulis di atas JavaScript, yang menambahkan type — semacam label kecil yang menjelaskan suatu nilai itu jenisnya apa (angka, teks, daftar user, dan seterusnya). Label-label itu sangat membantu selagi kamu menulis kode, karena menangkap kesalahan lebih awal. Tapi label itu tidak berarti apa-apa bagi mesin yang akhirnya menjalankan program.

Maka harus ada satu langkah yang mengubah TypeScript kamu menjadi JavaScript biasa. Langkah itu disebut compile (kamu juga akan mendengar istilah “transpile” — untuk keperluan kita, anggap saja sama). Alat yang melakukannya adalah compiler TypeScript.

Berkenalan dengan compiler: tsc

Compiler TypeScript adalah sebuah program bernama tsc (singkatan dari TypeScript compiler). Tugasnya membaca berkas .ts milikmu, memeriksa apakah ada kesalahan type, lalu menuliskan berkas .js yang setara.

Kamu memasangnya lewat npm, package manager yang ikut terpasang bersama Node.js. Umumnya tsc dipasang di dalam proyek, bukan secara global di seluruh komputer, supaya setiap proyek bisa mengunci versinya sendiri:

npm install --save-dev typescript

Bagian --save-dev artinya “ini alat untuk pengembangan, bukan sesuatu yang dibutuhkan aplikasi saat berjalan.” Setelah terpasang, kamu bisa menjalankan compilernya:

npx tsc --version

npx adalah pembantu kecil yang menjalankan alat yang sudah terpasang di proyek. Kalau nomor versi muncul, berarti compiler siap dipakai.

Sekarang bayangkan kamu punya berkas mungil bernama app.ts:

function greet(user: { name: string }): string {
  return "Halo, " + user.name;
}

const jane = { name: "Jane Doe" };
console.log(greet(jane));

Compile berkas itu:

npx tsc app.ts

Compiler membaca app.ts, memeriksa type-nya (di sini ia memastikan greet menerima objek dengan name berupa teks), lalu menghasilkan app.js tepat di sebelahnya. Berkas app.js itu adalah JavaScript polos dengan label type yang sudah dilepas — dan berkas itulah yang benar-benar bisa dijalankan.

Apa yang sebenarnya dihapus saat compile

Akan lebih jelas kalau kamu melihat sebelum dan sesudahnya. TypeScript di atas berubah kurang lebih menjadi JavaScript berikut:

function greet(user) {
  return "Halo, " + user.name;
}

const jane = { name: "Jane Doe" };
console.log(greet(jane));

Perhatikan apa yang hilang: : { name: string } dan : string. Itulah type-nya. Mereka menuntun compiler selagi memeriksa pekerjaanmu, lalu dihapus, karena program yang berjalan tidak membutuhkannya. Ini model berpikir yang penting — type ada saat compile, bukan saat program berjalan. Type adalah jaring pengaman selama pengembangan yang dilipat habis sebelum kode dikirim.

Peran tsconfig.json

Menjalankan tsc app.ts satu per satu masih wajar untuk satu berkas. Tapi proyek sungguhan punya puluhan atau ratusan berkas, ditambah setumpuk preferensi: versi JavaScript apa yang dituju, output ditaruh di mana, seketat apa pemeriksaannya. Mengetik semua itu di command line setiap kali tentu menyiksa.

Di sinilah tsconfig.json berperan. Ia satu berkas konfigurasi yang berada di akar proyek dan memberi tahu compiler harus berperilaku seperti apa. Saat kamu menjalankan tsc tanpa menyebut nama berkas, compiler mencari tsconfig.json, membaca preferensimu dari situ, lalu meng-compile seluruh proyek sesuai itu.

Kamu bisa membuat berkas awalnya:

npx tsc --init

Versi tsconfig.json yang minimal dan mudah dibaca bisa tampak seperti ini:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true
  },
  "include": ["src"]
}

Mari kita baca seperti cara compiler membacanya:

Gagasan besarnya: alih-alih menjelaskan proses build berulang-ulang, kamu menjelaskannya sekali di tsconfig.json, dan setelah itu sebuah perintah tsc polos sudah melakukan hal yang benar.

Memisahkan sumber dari output

Perhatikan bagaimana konfigurasi di atas menjaga rootDir (src) dan outDir (dist) tetap terpisah. Ini kebiasaan yang layak ditumbuhkan. TypeScript yang kamu tulis sendiri tinggal di src. JavaScript hasil bikinan compiler mendarat di dist. Kamu tidak pernah menyunting berkas di dist secara manual — berkas itu dibangun ulang dari src setiap kali kamu compile.

Tata letak yang umum tampak seperti ini:

my-project/
├─ src/
│  └─ app.ts        ← ini yang kamu tulis
├─ dist/
│  └─ app.js        ← ini yang dihasilkan tsc
├─ tsconfig.json    ← pengaturan compiler
└─ package.json     ← proyek + dependensi

Memisahkan kedua folder membuat pekerjaan aslimu tetap rapi, dan kamu aman saja menghapus dist kapan pun — ia akan muncul lagi pada build berikutnya. (Lazim juga menyuruh version control mengabaikan dist sepenuhnya, karena ia selalu bisa dibangun ulang.)

Watch mode: compile sambil mengetik

Menjalankan tsc ulang setiap kali ada perubahan cepat membosankan. Compiler punya jawaban bawaan bernama watch mode. Kamu menyalakannya sekali, lalu ia terus berjalan, meng-compile ulang otomatis begitu kamu menyimpan berkas:

npx tsc --watch

Sekarang alurnya jadi: sunting berkas, simpan, dan compiler langsung membangun ulang serta memeriksa semuanya. Kalau kamu membuat kesalahan type, kesalahannya langsung muncul di terminal, bukan menunggu sampai kamu ingat untuk compile. Untuk pengembangan sehari-hari, mode inilah yang biasanya kamu biarkan terus menyala di pojok layar.

Posisi TypeScript di dalam toolchain modern

Di sinilah banyak pemula bingung, jadi mari kita beresi. Di proyek kecil, tsc mengerjakan dua tugas sekaligus: ia memeriksa type kodemu, dan ia menghasilkan output JavaScript. Sederhana dan utuh dalam satu alat.

Tapi di proyek yang lebih besar atau di proyek front-end, kamu sering menemukan susunan yang berbeda. Sebuah build tool terpisah (bundler) bertugas mengubah banyak berkasmu menjadi aset akhir yang dimuat browser, dan ia menangani konversi TypeScript-ke-JavaScript sebagai bagian dari proses itu — biasanya cukup dengan melepas type-nya, sangat cepat, tanpa memeriksa type.

Itu terdengar bertentangan sampai kamu memisahkan dua tanggung jawabnya:

   Yang diberikan TypeScript
   ┌─────────────────────────────┐
   │ 1. Pemeriksaan type         │ ← menangkap kesalahan (kebenaran)
   │ 2. Lepas type → JS          │ ← menghasilkan kode yang bisa jalan
   └─────────────────────────────┘

Toolchain modern sering memisahkan keduanya:

• Build tool / bundler mengurus langkah 2 dengan cepat, supaya aplikasimu jalan.
• Sebuah eksekusi tsc --noEmit terpisah mengurus langkah 1, memeriksa type tanpa menulis berkas output apa pun (--noEmit artinya “periksa, tapi jangan hasilkan JavaScript”).

Itulah sebabnya kadang kamu melihat proyek yang tsc-nya justru disetel tidak menghasilkan berkas sama sekali. Itu bukan rusak — build tool yang menangani pembuatan berkas, dan tsc dipersempit ke satu hal yang paling ia kuasai: jadi sumber kebenaran untuk ketepatan type.

Kamu tidak perlu menghafal setiap variasinya. Yang perlu kamu bawa adalah pemisahannya: “membuat kode bisa jalan” dan “memastikan type-nya benar” adalah dua tugas berbeda, dan alat yang berbeda bisa memegang masing-masing.

Titik awal yang bersih, dari awal sampai jadi

Kalau dirangkai, penyiapan dari nol untuk proyek kecil hanya beberapa langkah:

# 1. Mulai sebuah proyek
npm init -y

# 2. Tambahkan compiler TypeScript sebagai alat pengembangan
npm install --save-dev typescript

# 3. Buat tsconfig.json
npx tsc --init

# 4. Tulis kode di src/, lalu compile
npx tsc

# 5. Atau kembangkan dengan recompile otomatis
npx tsc --watch

Dari sini kamu biasanya menambahkan script di package.json agar bisa menjalankan npm run build daripada mengingat perintah mentahnya — tapi itu sekadar pemanis. Model berpikir di baliknya tetap persis sama.

Rangkuman

TypeScript memang menambah langkah penyiapan kecil tapi nyata, dan sekarang kamu tahu kenapa serta apa tugas tiap bagiannya:

• TypeScript untuk ditulis; JavaScript untuk dijalankan. Compiler menjembatani keduanya.
• tsc adalah compiler itu. Kamu memasangnya per proyek dengan npm dan menjalankannya lewat npx tsc.
• Compile memeriksa type-mu dan menghasilkan JavaScript polos, dengan label type yang sudah dilepas. Type hidup saat compile, bukan saat program berjalan.
• tsconfig.json adalah berkas pengaturan proyek. Jelaskan build-mu sekali di situ, lalu tsc polos mengerjakan sisanya. Mulai dengan strict: true dan jaga sumber (src) terpisah dari output (dist).
• Watch mode (tsc --watch) meng-compile ulang otomatis saat kamu menyimpan, mempersempit jeda umpan balik.
• Di toolchain modern, pemeriksaan type dan pembuatan kode sering dibagi antara tsc dan sebuah build tool. Menyadari bahwa keduanya adalah dua tugas terpisah itulah yang membuat penyiapan di dunia nyata tidak lagi terasa seperti sihir.

Kuasai bagian ini, dan sisa perjalanan TypeScript-mu berdiri di atas dasar yang kokoh. Selebihnya — konfigurasi yang lebih rumit, framework, tooling yang lebih besar — hanyalah variasi dari segelintir ide yang baru saja kamu pelajari.