Rilis Deno 2.4

 (deno.com)
2 poin oleh GN⁺ 2025-07-08 | 1 komentar | Bagikan ke WhatsApp
  • deno bundle diperkenalkan kembali dengan basis esbuild, sehingga kini memungkinkan pembuatan bundle satu file untuk server maupun browser, lengkap dengan tree shaking dan optimisasi otomatis
  • Dukungan import teks/byte serta stabilisasi OpenTelemetry bawaan meningkatkan observabilitas dan pengalaman memanfaatkan file eksternal
  • Flag --preload baru, peningkatan kemudahan dependensi lewat deno update, pengukuran cakupan skrip, manajemen izin, hingga kompatibilitas API Node.js mendapatkan peningkatan luas
  • Peningkatan dukungan LSP, Jupyter, bench/coverage, tsconfig serta berbagai perbaikan kenyamanan penggunaan juga ikut hadir

Ringkasan perubahan utama dan fitur baru di Deno 2.4

Kembalinya deno bundle

  • Di Deno 2.4, subcommand deno bundle untuk membuat bundle JavaScript satu file kembali hadir bersama mesin esbuild
  • Mendukung server dan browser, serta dapat membundel dependensi npm, JSR tanpa masalah
  • Dengan dukungan tree shaking otomatis dan optimisasi kode (minify), pengelolaan menjadi lebih praktis
  • Ke depannya, fitur perluasan dan kustomisasi proses bundling secara terprogram akan ditambahkan melalui runtime API dan plugin

Dukungan import teks dan byte

  • Untuk memungkinkan penyematan file data eksternal seperti teks, biner, gambar ke dalam graph modul JavaScript, tersedia flag --unstable-raw-imports
  • Sebelumnya file eksternal harus dibaca lewat file I/O, tetapi kini tipe file dapat ditentukan di sintaks import untuk memakai data byte/teks secara langsung
  • Fitur ini juga berfungsi saat bundling dan kompilasi, sehingga embedding aset ke dalam hasil akhir menjadi mudah
  • Bersama dukungan import yang sudah ada seperti JSON dan Wasm, berbagai format file dapat dikelola dengan cara yang ramah spesifikasi
  • Walau pembahasan spesifikasi masih berlangsung, Deno berupaya menyeimbangkan kemajuan fitur dan arah standar

Stabilisasi OpenTelemetry bawaan

  • Dukungan OpenTelemetry bawaan yang diperkenalkan pada versi 2.2 kini sepenuhnya stabil di 2.4
  • Cukup atur variabel lingkungan OTEL_DENO=1, maka pengumpulan log, metrik, dan trace dapat diotomatisasi tanpa flag tambahan
  • Mendukung kompatibilitas tanpa konfigurasi dengan Node.js serta lingkungan deployment Deno Deploy
  • Juga memungkinkan pengaitan/pengamatan otomatis untuk log console.log dan permintaan HTTP
  • Karena karakteristik penggunaan sumber daya, kontrol lewat variabel lingkungan tetap diperlukan

Flag --preload untuk penyiapan lingkungan sebelum eksekusi

  • Ditambahkan flag --preload untuk mengeksekusi lebih dulu kode yang diperlukan bagi perubahan lingkungan global, pemuatan data, pendaftaran modul dependensi, dan lain-lain sebelum skrip utama berjalan
  • Berguna saat membangun platform seperti kustomisasi platform atau pengaturan ulang objek global
  • Dapat dipakai di perintah utama seperti deno run, deno test, deno bench, dan lainnya

Penyederhanaan manajemen dependensi: deno update

  • Diperkenalkan subcommand deno update untuk pembaruan otomatis ke versi terbaru dari dependensi npm dan JSR
  • Mendukung pembaruan banyak dependensi sekaligus serta pembaruan presisi berbasis kompatibilitas Semver
  • Juga tersedia sebagai alias dari deno outdated --update, sehingga lebih nyaman digunakan

Cakupan skrip: deno run --coverage

  • Kini dimungkinkan mengumpulkan cakupan tidak hanya untuk tiap pengujian, tetapi juga seluruh eksekusi yang mencakup subprocess
  • Pengelolaan data yang fleksibel tersedia lewat berbagai cara, termasuk variabel lingkungan DENO_COVERAGE_DIR
  • Dukungan mode gelap juga ditambahkan untuk laporan cakupan HTML

Variabel lingkungan kompatibilitas Deno DENO_COMPAT=1

  • Variabel DENO_COMPAT=1 diperkenalkan untuk meningkatkan kenyamanan dan kompatibilitas pada ekosistem npm serta proyek berbasis package.json
  • Secara otomatis menerapkan beberapa flag Unstable, dan ke depan cakupan dukungannya akan diperluas, termasuk penghilangan kebutuhan npm prefix

Peningkatan manajemen izin dan keamanan

  • Flag --allow-net kini mendukung wildcard subdomain dan rentang CIDR
  • Ditambahkan flag --allow-import untuk membatasi host yang boleh diimpor oleh kode, serta --deny-import untuk memblokir secara eksplisit
  • API Deno.permissions kini secara resmi mendukung query tipe "import"
  • Saat memakai Deno.execPath(), kini izin baca tidak lagi diperlukan, sehingga pemanfaatan path executable jadi lebih mudah

Conditional package.json exports

  • Dukungan untuk conditional exports pada paket npm ditambahkan, memperkuat dukungan lintas ekosistem termasuk konfigurasi server React
  • Perilaku import yang fleksibel dan terpersonalisasi dapat diwujudkan lewat flag kondisi pengguna

Dukungan bare specifier di deno run

  • Entry point perintah kini dapat dijalankan dengan alias (bare specifier) yang diatur di "imports" pada deno.json
  • Ini memberi kemudahan besar untuk produktivitas pengembangan dan otomatisasi manajemen modul

Peningkatan formatting kode untuk format seperti XML dan SVG

  • deno fmt kini mendukung formatting otomatis untuk berbagai file template seperti .xml, .svg, .mustache

Peningkatan dukungan tsconfig.json

  • Akurasi pengenalan berbagai opsi seperti references, extends, files, include, exclude ditingkatkan
  • Menawarkan kompatibilitas yang lebih baik dengan framework frontend modern seperti Vue, Svelte, Solid, dan Qwik

Peningkatan kompatibilitas variabel global dan API Node

  • Objek global Node.js seperti Buffer, global, setImmediate, clearImmediate kini selalu tersedia juga di kode pengguna
  • Global yang sebelumnya hanya untuk paket npm kini bisa langsung digunakan tanpa flag perintah
  • Kompatibilitas lebih dari 95% telah dicapai untuk node:buffer, node:events, node:querystring, node:quic, node:wasm, dan akan terus diperluas
  • Versi default tipe @types/node juga diperbarui ke 22.15.14

Perubahan manajemen paket npm lokal

  • Nama opsi koneksi paket lokal npm berubah dari patch menjadi links, agar selaras dengan makna npm link
  • Saat opsi lama dipakai, akan muncul peringatan deprecation, sehingga manajemen paket menjadi lebih jelas

Peningkatan LSP dan produktivitas pengembangan

  • Bersamaan dengan peningkatan performa dan fitur LSP, juga hadir berbagai kemudahan seperti dukungan socket Unix/Vsock pada fetch, callback onListen pada server, manajemen kernel Jupyter, pembacaan komentar di plugin lint, serta kompatibilitas Markdown untuk tabel bench/coverage
  • Pengenalan sinyal Ctrl+Close di Windows (windows SIGHUP) dan format Markdown untuk output teks bench/coverage juga ikut ditingkatkan

Ucapan terima kasih kepada komunitas dan kontributor

  • Perkembangan Deno 2.4 sangat terbantu oleh partisipasi dan umpan balik dari berbagai kontributor komunitas
  • Untuk informasi lebih lanjut dan rincian perubahan lengkap, lihat halaman rilis GitHub

Kesimpulan

  • Deno 2.4 menghadirkan kemajuan besar di berbagai aspek seperti bundling, import file eksternal, observabilitas, izin/keamanan, kompatibilitas, dan produktivitas
  • Dalam alur kerja pengembangan serta proyek frontend modern dan ekosistem Node, pengguna bisa merasakan lingkungan pengembangan terintegrasi yang mudah dan kuat
  • Informasi tambahan, berita terbaru, dan riwayat perubahan lengkap dapat dilihat di dokumentasi resmi, blog, dan halaman rilis GitHub

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-08
Komentar Hacker News

  • Saya sangat menyukai konsep Deno, jadi saya pernah mencoba menerapkan semaksimal mungkin Deno.json, JSR, modern import, Deno Deploy, dan lain-lain pada proyek monorepo yang mencakup Next.js, Hono, serta paket privat. Hono berjalan rapi, tetapi Next.js tidak, dan ada juga kasus di mana isu terkait tipe rusak secara halus. Saya juga ingat pemilihan target deployment (seperti Vercel) menjadi masalah. Sebagai contoh, saya membagikan masalah kecil yang saya alami melalui tautan issue. Sebaliknya, Bun memang tidak serapi Deno dari sisi pengalaman penggunaan, tetapi terasa lebih sedikit yang perlu dipikirkan dan kesannya "langsung jalan". Meski begitu, Bun juga tidak sempurna, misalnya runtime Bun belum didukung di Vercel

    • Ada saran bahwa stack yang dipilih masih berpusat pada npm, terutama di lingkungan dengan banyak paket npm privat, sehingga memang terasa dipaksakan. Menurut saya, daya tarik manis ala Deno justru ada pada memilih stack yang secara bawaan ramah Deno atau ESM. Pengalaman memakai Lume atau menargetkan Deno Deploy cukup bagus. (Skor JSR juga membantu untuk menjelajahi library yang menarik dan kuat dalam kompatibilitas ESM.) Tentu saja, menyarankan untuk memulai dengan stack yang benar-benar baru itu sulit secara realistis, dan investasi yang sudah ada pada Next.js dan sejenisnya juga besar, jadi berat untuk merekomendasikan Deno. Namun, saya rasa keunggulan Deno paling terlihat di lingkungan yang memulai dari nol dengan tool yang Deno-native dan ESM-native. Sebagai catatan, kompatibilitas npm di Deno terus membaik, dan catatan rilis 2.4 juga memuat peningkatan terkait ini. Di lingkungan full-stack, pendekatan yang mengutamakan package.json alih-alih deno.json justru lebih kompatibel, jadi walaupun dalam jangka panjang ingin mendorong deno.json, pengaturan berbasis package json juga layak direkomendasikan

    • Saat mencoba Deno dalam mode kompatibilitas npm, kesannya ternyata berjalan cukup baik. Cara pemakaiannya sangat mirip dengan Bun. Jika menjalankan deno install di direktori yang memiliki package.json, ia akan membuat node_modules yang ramping, dan perintah deno task something bisa menjalankan skrip yang didefinisikan di package.json. Namun, cara khas Deno sendiri sering kali memakan banyak waktu sehingga terasa membuat frustrasi, dan saat ingin kembali ke lingkungan node/npm malah jadi makin merepotkan. Kesimpulannya, memakai Deno bersama package.json terasa lebih mudah

    • Awalnya saya all-in ke Deno, tetapi terlalu banyak masalah kecil sehingga melelahkan. Sebagai perbandingan, Bun berjalan baik tanpa banyak hal yang perlu dipikirkan

  • Orang cenderung meremehkan kompatibilitas node di Deno. Saya berharap adopsi variabel lingkungan compat akan membantu penyebarannya. Akan lebih nyaman kalau command seperti denon menyalakannya secara otomatis

    • Dalam pengalaman saya, kompatibilitas node di Deno justru di bawah ekspektasi dan mengecewakan. Memindahkan proyek sederhana sekitar 100~200 baris ke Deno memakan waktu sekitar 1 jam, padahal seharusnya normalnya selesai dalam 5~10 menit. Beberapa method node tidak didukung, dokumentasi terkait juga kurang memadai, dan bahkan fitur dasar harus diunduh langsung dari URL yang obscure. Saat memindahkan test suite, saya akhirnya menyerah. Terutama, proses berpindah dari CommonJS (CJS) ke ESM jauh lebih menyakitkan dari yang dibayangkan, dan sama sekali tidak semudah yang dijelaskan dokumentasi resmi Deno. Pada akhirnya saya mengalami bahwa seluruh library tidak bisa dipindahkan

    • Dulu saya cukup positif terhadap Deno, tetapi sekarang saya tidak benar-benar merasa ada alasan untuk memakai Deno dibanding Bun

  • Ada penilaian bahwa daftar perubahan terbaru Deno itu bagus. Saya cukup puas memakai Deno untuk menulis skrip acak/glue code (untuk machine learning dan semacamnya saya memakai python/uv), dan saya juga menantikan dukungan gRPC serta command bundle di masa mendatang

  • Masih terasa aneh bahwa Deno sampai sekarang belum benar-benar berjalan baik di FreeBSD. Binding V8 berbasis Rust masih belum di-port

    • Saya penasaran sebenarnya ada berapa banyak pengguna FreeBSD di antara developer JavaScript modern

    • Dulu portabilitas antar-Unix dianggap ukuran kebersihan kode, tetapi sekarang saya heran karena kompatibilitas di antara berbagai sistem Unix tidak terlalu ditekankan lagi

    • Sepertinya sudah terdaftar di port untuk FreeBSD

    • Sangat bisa dimaklumi kenapa mereka tidak mengerahkan banyak upaya untuk dukungan FreeBSD

  • Ada pendapat bahwa alasan Deno belum lebih luas dipakai di production adalah ketiadaan database kerentanan yang terstandarisasi. Ini bisa ditutupi dengan kompatibilitas npm 100%, tetapi kalau begitu sebagian besar paket Deno populer justru keluar dari cakupan. Pada dasarnya, tidak adanya package manager terpusat (dan ini memang desain yang disengaja) adalah tantangannya. Ada yang bertanya apakah sudah ada perkembangan terkait hal ini

    • Bantahannya: jika ketiadaan database kerentanan benar-benar menjadi masalah besar di production, maka C/C++ juga sama-sama tidak bisa dipakai. Faktanya, untuk C/C++ orang memeriksa isu keamanan dengan merujuk pada database CVE/GHSA yang netral terhadap bahasa. Sebagai referensi, pada C juga sering kali orang cukup mem-vendoring file eksternal begitu saja tanpa melacak versinya. Selain itu, ada file deno.lock, jadi bagi yang peduli, mereka bisa bergantung pada file ini untuk memeriksa database kerentanan terhadap versi yang digunakan

    • Struktur mengambil paket langsung dari URL (seperti GitHub) juga mirip dengan Go, jadi isu yang sama berlaku juga untuk Go

  • Saya suka karena subcommand bundle ditambahkan kembali. Senang karena tidak perlu lagi memakai cara memutar yang merepotkan

  • Agak mengejutkan bahwa untuk pekerjaan bundling mereka memilih esbuild, bukan Rolldown berbasis Rust. Rolldown kabarnya segera mencapai v1

    • esbuild saat ini sangat stabil dan matang, sementara Rolldown masih berubah dengan cepat, jadi memilih esbuild terasa lebih aman

  • Saya sangat menyukai arah Deno, dan rasanya Node seharusnya sejak awal lahir seperti ini. Namun, yang saya khawatirkan adalah Deno ikut terseret tanpa perubahan oleh 'hype' para pesaingnya

    • Bisa juga dibilang Deno sendiri selama ini dipersepsikan sebagai pesaing berbasis 'hype' untuk Node.js

  • Saya terus mendengar penilaian bagus tentang Deno. Gara-gara itu saya mulai berpikir mungkin saya akan mencoba memakai js

    • Kalau sekarang, memulai langsung dengan TS juga pilihan yang bagus

  • Dari sudut pandang keamanan saya mendukung Deno, tetapi saya pernah merasa kurang nyaman karena situs resminya merekomendasikan instalasi dengan format curl mywebsite.com/foo.sh | sh. Tentu tingkat toleransi risiko tiap orang berbeda, tetapi setidaknya jika file diunduh lalu dijalankan, pengguna atau antivirus bisa memeriksanya. Ekosistem Node/Deno + npm pada dasarnya adalah struktur yang membutuhkan kepercayaan cukup besar. Panduan resmi juga menyediakan opsi npm install -g deno selain curl | sh, dan npm setidaknya punya pemeriksaan integritas file minimal serta pemindaian malware sederhana, sehingga relatif lebih aman. Situs deno.land pun, walaupun aman di level codebase, dari sisi operasional tidak bisa dijamin 100%, jadi menurut saya curl | sh bukan praktik terbaik keamanan

    • Saya tidak setuju dengan logika ini. Kebanyakan skrip instalasi pada akhirnya hanya bertugas mengunduh dan menjalankan biner berukuran ratusan hingga jutaan baris yang dibuat oleh penulis yang sama. Jika sampai tidak bisa mempercayai penulis sama sekali, sehingga mengasumsikan server bisa menyebarkan malware hanya ke IP tertentu, maka malware juga bisa disisipkan di level biner sejak awal, jadi seharusnya proyek itu memang tidak dipakai sama sekali. Perdebatan curl | sh tampaknya meluas karena itu argumen yang mudah dan bisa diulang-ulang, padahal meninjau jutaan baris kode justru masalah keamanan yang sesungguhnya. Jika sampai khawatir pada serangan MITM oleh lembaga pemerintah, satu-satunya jalan adalah memutus seluruh kepercayaan ke internet luar sejak awal

    • Ada catatan bahwa onboarding pengguna baru memang sulit. Bahkan jika menyarankan untuk memakai npm, npm sendiri harus sudah terpasang lebih dulu, sementara situs resmi npm menyarankan instalasi nvm, dan nvm pun menggunakan curl | sh. Jadi pada akhirnya pendekatan lewat npm juga secara tidak langsung menghadapi masalah yang sama

    • Dalam diskusi apakah npm install -g deno benar-benar lebih aman daripada curl | sh, inti persoalannya bergantung pada: mana yang lebih mudah ditembus peretas, server npm atau server milik sendiri? Jika kita yakin ini bukan soal kompromi server sendiri, maka tidak ada alasan curl | sh lebih tidak aman daripada npm install. Pada akhirnya, dari sudut pandang keamanan, kedua metode ini sama-sama bisa rentan, jadi jika didekati secara ekstrem, masalahnya justru adalah penggunaan internet itu sendiri

    • Kritik bahwa implementasi sandbox Deno terasa seperti teknologi era 90-an, sehingga memakainya sendiri bukan kebiasaan keamanan yang baik

    • Ada yang penasaran apakah pernah ada contoh serangan terhadap model instalasi curl | sh yang benar-benar berhasil di dunia nyata