Referensi Kompatibilitas

Sepanjang Course ini kita memakai fitur dari berbagai generasi Node.js: fetch global yang lahir di generasi 17-18, node:sqlite yang baru matang di generasi 24, sampai type stripping yang menjadi bawaan di antara keduanya. Sebelum kode semacam itu dikirim ke server lain, satu pertanyaan wajib dijawab: versi Node.js minimum berapa yang kita butuhkan? Chapter ini menutup Course dengan tiga bekal: tempat-tempat resmi untuk memeriksa ketersediaan fitur, matriks versi untuk seluruh fitur yang dipakai Course, dan pola deteksi fitur di runtime untuk kode yang harus lintas versi. Semua angka pada matriks diverifikasi langsung dari tabel History dokumentasi resmi garis 24.

Tiga Tempat Memeriksa Ketersediaan Fitur #

Pemeriksaan tercepat dilakukan di tiga tempat, masing-masing menjawab kebutuhan berbeda. Pertama, kolom Added in: dan tabel History pada referensi API — sumber paling otoritatif karena diterbitkan bersama kodenya; inilah yang kita latih pada Chapter Membaca Referensi API. Kedua, changelog rilis di GitHub yang memotret seluruh perubahan per versi, berguna saat kita menaikkan versi dan ingin tahu apa saja yang ikut berubah. Ketiga, jadwal rilis resmi beserta daftar rilis sebelumnya yang menjelaskan garis mana yang masih hidup dan sampai kapan — bahan keputusan versi produksi, bukan versi fitur.

Matriks Fitur Course #

Tabel berikut merangkum fitur-fitur Course beserta versi pertama ketersediaannya, sesuai tabel History dokumentasi resmi. Angka pada kolom kedua adalah versi tertua yang mendukung fitur pada garisnya; catatan di kolom ketiga melengkapi dengan tonggak stabilitasnya:

Dua kebiasaan membaca matriks ini: pertama, perhatikan bahwa garis LTS menerima banyak fitur melalui backport — fitur bisa hadir di garis 20 pada v20.13.0 meskipun lahir di garis 22; kedua, status “tersedia” belum berarti “stabil”, seperti kasus node:sqlite yang baru menjadi kandidat stabil di v24.15.0. Untuk memahami arti tiap tingkat stabilitas, kembali ke tabel indeks stabilitas pada Chapter Membaca Referensi API.

Deteksi Fitur di Runtime #

Matriks menjawab kebutuhan penulis kode; runtime target kita, kodenya sendiri yang bisa bertanya. Deteksi fitur memeriksa keberadaan API sebelum dipakai, sehingga satu berkas kode bisa memberi jalur cadangan di versi lama. Berkas deteksi-fitur.mjs memperlihatkan tiga polanya sekaligus:

// Deteksi fitur: pola ini berjalan di banyak versi Node.js
console.log(`fetch               : ${typeof fetch}`);
console.log(`structuredClone     : ${typeof structuredClone}`);

try {
  const { DatabaseSync } = await import("node:sqlite");
  console.log(`node:sqlite         : ${typeof DatabaseSync === "function" ? "tersedia" : "tidak"}`);
} catch {
  console.log("node:sqlite         : tidak tersedia");
}

console.log(`type stripping      : ${process.features.typescript}`);

Output yang Dihasilkan:

fetch               : function
structuredClone     : function
node:sqlite         : tersedia
type stripping      : strip

Mari kita telaah tiga pola di dalamnya:

1. Baris 3-4 (typeof): untuk nilai global seperti fetch, cukup periksa hasil typeof — "function" berarti tersedia. Pola ini yang diperkenalkan pada Chapter Versi Node.js dan Kompatibilitas lewat structuredClone.
2. Baris 7-11 (await import dalam try): untuk core module, impor dinamis di dalam try...catch mendeteksi ketersediaannya tanpa menghentikan program; di Node.js 24 pemanggilan berhasil, di versi lebih tua cabang catch yang berjalan.
3. Baris 13 (process.features.typescript): property resmi pelengkap deteksi — bernilai "strip" saat type stripping aktif (bawaan Node.js 24), "transform" bila flag --experimental-transform-types dipakai, dan false bila dinonaktifkan.

Deteksi fitur cocok untuk pustaka yang menopang banyak pengguna. Untuk aplikasi milik sendiri, deklarasi engines pada package.json umumnya lebih jujur: kebutuhan versi dinyatakan terbuka dan pemasangan di runtime yang salah langsung terdeteksi — kedua pendekatan ini saling melengkapi, bukan saling menggantikan.

Garis Rilis Hari Ini #

Sebagai bahan keputusan versi produksi, berikut kondisi garis rilis per jadwal resmi saat Course ini ditulis:

Dengan matriks di tangan, keputusan versi minimum menjadi aritmetika sederhana: ambil fitur termuda yang dipakai aplikasi, baca barisnya, lalu tetapkan garis LTS yang memenuhinya. Pengetahuan Semantic Versioning melengkapi keputusan yang sama dari sisi package: rentang dependensi yang terlalu longgar atau terlalu ketat sama-sama biaya perawatan di masa depan. Kerangka rujukan Course kini lengkap — dokumentasi resmi, cara membacanya, kosakatanya, panduan diagnosa, dan daftar periksa keamanan — dan kerangka itulah bekal terbaik untuk terus belajar jauh setelah halaman ini ditutup.