Deno 2: Kompatibilitas Node.js dan npm untuk Proyek Lama

Selama bertahun-tahun jawaban jujur atas pertanyaan apakah Anda bisa menjalankan basis kode Node sungguhan di Deno adalah tidak. Runtime-nya elegan, aman secara default, dan native TypeScript, tetapi ia mengabaikan package.json, menolak folder node_modules, dan menuntut Anda menulis ulang impor menjadi berbasis URL. Itu tembok yang tidak akan didaki kebanyakan tim untuk aplikasi yang sudah tayang di produksi.

Deno 2, yang dirilis pada Oktober 2024, meruntuhkan tembok itu. Judul utama rilis ini adalah kompatibilitas mundur dengan Node.js dan npm: Anda bisa mengarahkan Deno ke proyek yang sudah ada dan ia langsung jalan. Tulisan ini membahas apa yang benar-benar berubah dan mengapa saya kini menganggap Deno sebagai opsi serius untuk kode yang bukan saya tulis dari nol.

package.json dan node_modules kini kelas satu

Perubahan terbesar adalah Deno 2 memahami berkas yang sudah dimiliki proyek Node. Ia membaca package.json Anda, menghormati dependensi dan script-nya, serta akan membuat dan memakai direktori node_modules ketika perkakas Anda membutuhkannya. Tidak ada langkah konversi dan tidak ada manifes terpisah untuk dipelihara.

Dalam praktiknya Anda masuk ke repositori Node dan perintah yang sudah familier punya padanan langsung. deno install membaca package.json dan mengisi node_modules, sementara deno task menjalankan script yang sudah Anda definisikan di bidang scripts, sama seperti npm run.

# An existing Node project — nothing to rewrite
deno install                 # reads package.json, populates node_modules
deno task dev                # runs the "dev" script from package.json
deno run --allow-net server.js

Deno juga menghormati bidang package.json seperti type untuk resolusi modul dan engines untuk batasan versi, serta mendukung registry privat lewat berkas .npmrc Anda yang sudah ada. Hasilnya, aplikasi Node berbasis ESM sering kali berjalan di bawah Deno tanpa perubahan kode sama sekali.

Specifier npm, node, dan jsr berdampingan

Deno 2 meresolusi tiga jenis impor tanpa perkakas build apa pun. Prefiks npm menarik paket mana pun dari lebih dari dua juta paket di registry npm langsung dari kode sumber Anda, mengunduhnya saat pertama kali jalan ke cache global. Prefiks node menjangkau bawaan Node seperti fs dan process, dan prefiks jsr menarik dari JSR, registry native TypeScript.

// npm packages — no install step required
import express from "npm:express@4";
import chalk from "npm:chalk@5";

// Node built-ins via the node: prefix
import { readFile } from "node:fs/promises";
import process from "node:process";

// JSR — the TypeScript-native registry
import { serveDir } from "jsr:@std/http/file-server";

Satu CLI menggantikan seluruh toolchain

Bagian yang paling saya hargai sebagai pemelihara adalah Deno mengapalkan toolchain lengkap dalam satu binari. Tidak ada Prettier, ESLint, Jest, dan bundler terpisah yang harus dirangkai dan dijaga tetap selaras. Perintah deno memformat, melinting, menguji, menambah dependensi, dan mengompilasi.

deno add npm:zod        # add an npm dependency
deno add jsr:@std/assert  # add a JSR dependency
deno fmt                # format JS, TS, JSON, Markdown, HTML, CSS, YAML
deno lint               # lint with Node-specific rules
deno test               # runs Deno tests AND node:test suites
deno compile --output app main.ts   # single self-contained binary

deno fmt kini memformat JavaScript, TypeScript, JSON, Markdown, HTML, CSS, dan YAML. deno lint menambahkan aturan khusus Node. deno test menjalankan baik tes Deno maupun rangkaian node:test. deno compile menghasilkan satu berkas eksekusi mandiri, dan deno task menjalankan script package.json Anda. Cukup satu dependensi untuk dipasang dan diperbarui, bukan selusin.

Workspace dan monorepo hibrida

Deno 2 mendukung monorepo lewat bidang workspace di deno.json akar. Sebuah workspace adalah kumpulan folder anggota, dan yang penting tiap anggota bisa membawa deno.json atau package.json, sehingga Anda bisa mencampur paket native Deno dan native Node dalam satu repositori.

// deno.json at the repo root
{
  "workspace": ["./api", "./web", "./packages/shared"]
}

Model hibrida itulah yang membuat adopsi bertahap menjadi realistis. Anda bisa memigrasi satu paket dalam satu waktu alih-alih mengonversi seluruh monorepo dalam satu perubahan berisiko. Di seluruh workspace Deno dapat:

• Meresolusi dependensi antar paket anggota berdasarkan nama scoped-nya.
• Menjalankan tes, pemformatan, dan linting di setiap anggota dengan satu perintah.
• Memublikasikan anggota tertentu ke JSR sementara yang lain tetap di npm.

Stabilitas jangka panjang kini janji eksplisit

Hal lain yang diminta perusahaan adalah jaminan stabilitas, dan Deno 2 menjawabnya. Mulai Deno 2.1 proyek ini mengapalkan rilis dukungan jangka panjang: perbaikan bug kritis di-backport selama enam bulan, dan cabang LTS baru dibuat setiap enam bulan. Dipadu pustaka standar yang diaudit ketat dan diterbitkan di JSR, itu memberi tim ritme pembaruan yang dapat diprediksi.

Deno 2 versus Node.js sekilas

Jadi, haruskah Anda beralih?

Deno 2 membingkai ulang pertanyaannya. Ini bukan lagi soal beralih atau bertahan, melainkan seberapa banyak tumpukan Node Anda yang ingin dipertahankan. Karena ia membaca package.json, memakai node_modules, dan mengimpor dari npm, Anda bisa mengadopsinya secara bertahap dan berbalik arah dengan murah bila tidak cocok.

Rekomendasi saya pragmatis: coba Deno pada satu layanan internal kecil atau paket baru di monorepo Anda. Jika deno fmt, deno lint, deno test, dan deno compile membuat Anda bisa menghapus setumpuk konfigurasi dan dependensi dev, penyederhanaan itu saja sudah layak dicoba, dan Anda tetap punya setiap jalan keluar kembali ke Node.