Versi Node.js dan Kompatibilitas

Sebagai runtime yang berkembang aktif, Node.js merilis versi major baru setiap enam bulan — dan tidak semua versi diciptakan setara untuk kebutuhan produksi. Memilih garis versi yang salah bisa berarti fitur yang dijanjikan tutorial tidak tersedia, atau versi yang sudah kehilangan dukungan keamanan. Chapter ini membekali kita dengan tiga keterampilan praktis: membaca nomor versi Node.js, memahami siklus rilis beserta status Current dan LTS, dan mengecek kompatibilitas sebuah fitur dengan versi yang kita pakai.

Membaca Nomor Versi #

Node.js mengikuti spesifikasi Semantic Versioning dengan pola MAJOR.MINOR.PATCH. Contohnya versi 24.21.0 yang dipakai Course ini:

Dengan tabel ini, kita langsung tahu bahwa 24.21.0 adalah rilis ke-21 (fitur) pada garis major 24 tanpa perbaikan tambahan. Versi major inilah yang menjadi acuan saat orang berkata “Node 22” atau “Node 24”.

Siklus Rilis dan Statusnya #

Node.js memotong versi major baru setiap enam bulan: versi genap dirilis pada April dan versi ganjil dirilis pada Oktober. Nasib keduanya berbeda:

• Versi ganjil hanya menikmati status Current sekitar enam bulan, lalu berakhir tanpa pernah menjadi LTS. Versi ini cocok untuk mencoba fitur terbaru, bukan untuk produksi.
• Versi genap beralih menjadi Long Term Support (LTS) pada bulan Oktober tahun yang sama — tepatnya ketika versi ganjil baru dirilis. Sejak saat itu garis LTS dipelihara 12 bulan berstatus Active LTS, lalu dilanjutkan 18 bulan berstatus Maintenance LTS — total sekitar 30 bulan dukungan.

Tiga fase tersebut punya arti praktis yang berbeda:

Garis Rilis Terkini #

Tabel berikut merangkum garis rilis terbaru sesuai jadwal rilis resmi , terverifikasi per pertengahan Oktober 2026:

Tanggal pada jadwal resmi bisa bergeser beberapa hari, dan status tiap garis berubah seiring waktu — daftar rilis sebelumnya di nodejs.org selalu memuat kondisi terkini beserta codename setiap garis sejak era Node.js 0.x.

Melihat Versi dari Dalam Program #

Selain perintah node --version di terminal, kita juga bisa membaca informasi versi dari dalam kode JavaScript lewat object process:

console.log(`Versi penuh  : ${process.version}`);
console.log(`Garis LTS    : ${process.release.lts}`);
console.log(`Versi V8     : ${process.versions.v8}`);
console.log(`Versi libuv  : ${process.versions.uv}`);

Output yang Dihasilkan:

Versi penuh  : v24.21.0
Garis LTS    : Krypton
Versi V8     : 13.6.233.17-node.53
Versi libuv  : 1.52.1

Mari kita telaah baris-baris kode di atas:

1. Baris 1 (process.version): string versi lengkap termasuk awalan v, misalnya v24.21.0.
2. Baris 2 (process.release.lts): codename garis LTS yang sedang berjalan — Krypton untuk Node.js 24. Pada build yang bukan LTS, property ini bernilai undefined.
3. Baris 3-4 (process.versions.v8 dan process.versions.uv): versi V8 dan libuv yang tertanam pada runtime. Nilai-nilai ini menjelaskan mengapa fitur bahasa dan perilaku I/O bisa berbeda antar garis major.

Kompatibilitas Fitur antar Versi #

Dua hal menentukan ketersediaan sebuah fitur: versi V8 yang tertanam (untuk fitur bahasa seperti sintaks baru), serta versi Node.js saat sebuah API diperkenalkan (misalnya node:sqlite yang baru stabil pada Node.js 24). Dokumentasi API resmi selalu mencantumkan penanda Added in: — misalnya, fetch global tersedia sejak Node.js 18 — sehingga halaman dokumentasi adalah rujukan tercepat sebelum memakai API di versi lama.

Untuk library yang kita tulis sendiri, deklarasikan kebutuhan versi lewat field engines agar pengguna terlindung dari runtime yang tidak sesuai:

{
  "name": "layanan-tugas",
  "version": "1.0.0",
  "engines": {
    "node": ">=24"
  }
}

Terakhir, kode yang harus berjalan di beberapa versi sekaligus dapat memakai deteksi fitur — memeriksa keberadaan API sebelum menggunakannya:

console.log(`structuredClone tersedia: ${typeof structuredClone === "function"}`);

Output yang Dihasilkan:

structuredClone tersedia: true

Fungsi structuredClone hadir sejak Node.js 17, sehingga pemeriksaan di atas mencetak hasil positif pada Node.js 24 yang kita pakai sekarang.

Kita kini tahu membaca nomor versi, memilih garis LTS untuk produksi, dan memeriksa ketersediaan fitur sebelum menulis kode. Fondasi pengenalan Node.js sudah lengkap — saatnya menyiapkan komputer kita: memasang Node.js versi yang tepat, mengatur editor, dan menjalankan proyek pertama di Section Persiapan Lingkungan.