Node.js kini mendukung menjalankan file TypeScript tanpa konfigurasi tambahan

• Node.js ditingkatkan sehingga dapat menjalankan file TypeScript secara langsung
• Kini file .ts dapat dijalankan langsung tanpa konfigurasi tambahan atau transpiling
• Developer dapat meningkatkan efisiensi kerja tanpa tsconfig.json atau pemasangan bundler terpisah
• Fitur ini resmi diterapkan mulai Node.js v22.18.0 (LTS)
• Diharapkan menghasilkan batas yang makin kabur antara pengembangan JavaScript dan TypeScript

---

Dukungan eksekusi TypeScript langsung di Node.js

• Node.js baru-baru ini memperkenalkan fitur untuk langsung menjalankan file TypeScript (.ts) pada versi v22.18.0 (LTS), tanpa konfigurasi atau alat terpisah
• Sebelumnya, untuk menjalankan kode TypeScript diperlukan transpiler eksternal atau bundler seperti ts-node, esbuild, dan Babel, tetapi kini Node.js sendiri dapat mengenali dan menjalankan kode TypeScript tanpa alat-alat tersebut
• Melalui fitur ini, developer kini dapat langsung menjalankan file .ts di Node.js tanpa file konfigurasi tsconfig.json maupun library tambahan
• Produktivitas dan kemudahan pengembangan meningkat besar untuk prototyping, pengembangan eksperimental, dan eksekusi skrip
• Diharapkan ada penguatan keterhubungan antara proyek JavaScript dan TypeScript, serta penurunan hambatan masuk bagi developer baru

Perubahan penting lainnya

• esm: implementasi import.meta.main
• fs: peningkatan penanganan event fs berbasis AsyncIterator
• permission: dukungan pengiriman flag model izin saat menjalankan subproses
• sqlite: penambahan opsi readBigInts
• src/permission: dukungan permission.has(addon)
• url: penambahan API fileURLToPathBuffer
• watch: penambahan flag --watch-kill-signal
• worker: objek Worker ditingkatkan menjadi async disposable

Pembaruan terkait commit dan dokumentasi

• Termasuk penghapusan kode yang tidak perlu, perapihan lingkungan build dan toolchain, serta upgrade ke npm 10.9.3
• Perbaikan indikator stabilitas terperinci dan nomor RFC pada dokumentasi seperti globals.md, child_process.md, dan http2
• Banyak penambahan test dan perbaikan bug juga telah diterapkan

File distribusi

• Tersedia installer dan biner untuk Windows, macOS (Intel/Apple Silicon), dan Linux (x64, ARM, PPC, s390x, AIX)
• Kode sumber dan file rilis lengkap dapat diunduh dari halaman distribusi resmi Node.js
• Dokumentasi API telah diperbarui berdasarkan v22.18.0

[aliveornot]

Wah, rasanya lega banget... semoga cepat jadi standar.

[tested]

Sepertinya cukup oke untuk menjalankan skrip sederhana, tetapi untuk proyek nyata ada banyak keterbatasan jadi rasanya tidak akan terlalu sering dipakai.

Karena ada error ERR_MODULE_NOT_FOUND/ERR_UNSUPPORTED_DIR_IMPORT, ekstensi maupun path juga harus disesuaikan.
Fitur seperti NestJS yang membutuhkan dukungan build TypeScript dengan pengaturan "emitDecoratorMetadata" juga tidak bisa digunakan, jadi...

[kimjeongwonn]

Apakah --experimental-strip-types diterapkan secara default?

[click]

Lagipula saya memang tidak memakai enum, jadi menurut saya pribadi, hanya dengan perilaku penghapusan tipe saja pun sudah berjalan dengan cukup baik.

[crawler]

Ini akan jadi sangat praktis!

[honglu]

Tidak bisa menahan buat kasih jempol.

Saya sudah merasa --no-experimental-strip-types saja sudah cukup bagus.

Bahkan sepertinya ini lebih bagus lagi.

[GN⁺]

Komentar Hacker News

• Dengan node:test di Node.js, menurut saya sekarang Node.js sudah menjadi pilihan default yang meyakinkan untuk hampir semua kasus. Menjalankan lewat tsx dulu memang sangat meningkatkan kualitas hidup, tapi tetap belum sepenuhnya lengkap. Penegasan tipe saat runtime di edge kini banyak terbantu oleh alat seperti zod, ts-rest, dan trpc, dan belakangan ini pengembangan full-stack Typescript benar-benar jadi sangat mudah
  • Benar sekali. Akhirnya pada 2025 ekosistem node menjadi cukup layak dipakai hanya dengan pengaturan bawaan. Modul ESM bekerja begitu saja baik di Node maupun Typescript, Node bisa langsung menjalankan file .ts, dan ada test runner bawaan yang cukup bagus (--watch didukung). Paket bawaannya juga makin baik. Misalnya node:fs/promises, berkat top-level await pekerjaan loop asinkron juga jadi jauh lebih mudah. Butuh waktu lama untuk meyakinkan semua orang agar mau memakai pendekatan yang realistis, tapi sekarang situasinya benar-benar nyaman
  • Saya sangat mendukung dukungan langsung Typescript di Node. Memang belakangan ini vitest membuat banyak hal jadi nyaman, tetapi saya sudah menghabiskan jauh lebih banyak waktu untuk menyiapkan lingkungan pengujian file .ts. Saya rasa trpc dan ts-rest adalah masalah yang sama sekali berbeda. Keduanya bisa dipakai, tetapi di production saya menghindari trpc karena saya tidak bisa benar-benar memiliki URL API saya sendiri, dan tidak bisa mengelola serta menghentikan URL lama secara alami. Untuk ts-rest juga, biasanya saya lebih suka berbagi zod dan tipe secara langsung untuk mengelola sendiri pasangan request/response API. Dan setiap kali trpc yang jelas-jelas alat RPC punya akhiran -rest di namanya, itu terasa mengganggu
  • Ke depan saya akan melihat apakah Sveltr memindahkan codebase-nya kembali ke Typescript
  • Saya penasaran apakah ini benar-benar menjalankan tsx. Walaupun tipenya dihapus, JSX tetap harus diubah menjadi JavaScript, jadi saya penasaran soal bagian itu
  • Saya belum lama ini beralih ke Python. Karena semuanya sudah bawaan, saya jauh lebih puas karena tidak perlu men-debug berbagai masalah aneh dari sistem yang belum matang
• Saya sangat terkesan dengan perkembangan Node dalam beberapa tahun terakhir. Menyenangkan melihat deno dan bun mendorong Node untuk melakukan perbaikan yang terfokus dan bermakna. Sempat stagnan cukup lama
  • Saya penasaran perbaikan apa saja yang baru-baru ini ada di Node. Terakhir kali saya merasa ada perubahan berarti adalah dukungan resmi untuk import/export (saya tidak tahu apakah hack .mjs masih diperlukan). Saya agak lama jauh dari ekosistem ini, jadi ingin tahu apa yang berubah setelah itu
  • Entah benar begitu atau tidak. Dari proyek-proyek yang saya ikuti, deno atau bun tidak ada pun tidak masalah sama sekali. Yang benar-benar berarti dalam praktik hanyalah rilis LTS node, dan proyek-proyek terbaru pun masih memakai node versi 20
• Sayang sekali Typescript tidak diterima dari node_modules (terkait: dokumentasi resmi node.js). Lalu saya penasaran bagaimana dengan dependensi proyek. Saya menulis library model data dalam Typescript, dan ingin mengimpornya ke aplikasi saya dalam bentuk Typescript. Saya penasaran apakah aturan ini hanya berlaku untuk paket npm, atau untuk semua dependensi. Di sini ada peluang. Saya membuat runtime berbasis golang untuk menjalankan typescript (tepatnya eksekusi JS secara umum), dan sepertinya sobek yang dipakai tim grafana juga hanya perlu menambah fitur type stripping. Kalau ada satu saja runtime yang benar-benar mengadopsi Typescript sebagai bawaan, rasanya Node.js akan benar-benar terdorong berinovasi. Tidak perlu transpiler, tidak perlu typescript-go, tidak perlu rust (meski rust tetap agak 😉), cukup sistem dengan parser yang baik yang bisa melacak source map dan tipe dalam mode debug. Bagaimanapun, apresiasi dan terima kasih untuk tim Node dan semua kontributor. Karena Node menjadi standar, rasanya kita semua mengikuti jejak itu. API embedding-nya juga sederhana dan rapi dipakai, jadi nyaman untuk membuat executable mandiri
  • Saya pernah meninggalkan komentar yang sama (referensi). Ada bagian “untuk mencegah didorongnya distribusi paket yang ditulis dalam typescript ke npm”, dan saya juga sempat mencoba dengan paket privat tetapi tetap tidak jalan, dan Node bahkan tidak peduli pada field "private" itu sendiri
  • Menurut saya paket memang harus dikompilasi ke JavaScript sebelum didistribusikan ke npm. Saya tidak melihat alasan mengapa Typescript mentah harus diunggah ke npm
• Isu terkait Saya juga merasa sayang tidak ada dukungan type stripping di node_modules
  • Separuh alasan saya menantikan fitur ini justru karena itu. Saya ingin bisa menulis library dalam Typescript, melakukan type-check hanya di CI/CD, lalu langsung mengimpornya di Node.js
  • Menurut saya itu keputusan yang benar. Typescript cukup sering mengalami breaking change. Selama belum distandardisasi, saya rasa pendekatan sekarang lebih baik
• Saya tidak terlalu banyak memakai JS/TS, tetapi saya penasaran apakah bukankah lebih baik langsung memakai Bun. Memang tidak semua proyek dimulai dari nol, tetapi saya merasa Bun secara keseluruhan adalah runtime yang lebih baik. Menjalankan TS bekerja sejak awal, resolusi dependensinya jauh lebih cepat, dan pengalaman pakainya juga sangat baik. Secara pribadi saya sudah memindahkan banyak proyek Node lama ke Bun, dan sejak Bun dirilis saya hampir tidak pernah lagi memakai Node. Kalau ada yang saya pahami keliru, mohon dikoreksi
  • Saya hanya memakai Node selama hampir 8 tahun lalu baru-baru ini pindah ke Deno. Perpindahan ini juga tidak mudah, dan yang menakutkan bukan karena benar-benar tidak jalan, melainkan karena saya tidak tahu kapan sesuatu tiba-tiba akan gagal. Node jelas punya banyak kekurangan, tetapi tetap menjadi standar de facto di industri. Ekosistem JS sendiri sudah cukup kacau, jadi banyak developer lelah dengan build tool, bundler, atau runtime baru. Sepertinya Bun belum mengumpulkan cukup stabilitas atau dukungan untuk benar-benar meyakinkan. Saya juga pernah menghabiskan beberapa hari hanya karena satu minor update TS
  • Saya tidak terlalu suka mengejar tren terbaru. NodeJS adalah runtime dengan dukungan terbaik di ekosistem JS. Saya rasa jauh lebih baik mengikuti pilihan yang menjadi default. Saya cenderung memilih teknologi yang disebut ‘membosankan’
  • Saya sudah beberapa kali mencoba beralih total sejak Bun dirilis, tetapi setiap kali selalu mentok di sekitar 90% karena masalah yang tak terhindarkan. Pada percobaan terakhir, beberapa library tidak berjalan karena fungsi napi belum diimplementasikan, dan saya juga ingat masalah seperti opsi recursive yang diabaikan pada opendir. Saya menunggu Bun mengejar ketertinggalan, tetapi sampai sekarang rasanya belum siap dipakai secara nyata di proyek besar. Fitur khusus bun juga terlihat bagus pada kesan pertama, tetapi di praktik terasa kurang matang. Dokumentasinya juga belum sebaik Node.js
  • Ini masalah kompatibilitas yang saya alami saat mencoba mengganti Node dengan Bun.
• localAddress diabaikan pada koneksi TCP
• Tidak kompatibel dengan API modul Node (contoh: proyek spamscanner tidak berjalan)
• Masalah race terkait EventEmitter (sebagian teratasi dengan eventemitter2)
• Dev server Svelte vites kadang macet sehingga saya harus menghapus node_modules lalu memasang ulang

  • Saya sudah mencoba fitur TS dan test runner bawaan Node, tapi masih belum sebagus Bun. Untuk sementara, kalau butuh fitur seperti itu saya masih memakai Bun. Di ekosistem Node, saya belajar bahwa lebih baik tidak all-in pada satu hal saja, melainkan menggabungkan alat yang masing-masing unggul di bidangnya.

    • Bun.js: untuk runtime Node, dipakai untuk menjalankan TS dan testing. Saya sudah mencoba bermacam-macam seperti TSX, TS-Node, dan Node bawaan

    • NPM: dipakai untuk menjalankan skrip tooling

    • PNPM: dipakai untuk memasang dependensi. (Menurut saya paling unggul dibanding npm, yarn, bun)

    • Biome.js: untuk linting. Lebih baik daripada alat linting mana pun yang pernah saya pakai

• Saya sangat suka bahwa peningkatan kali ini hanya berupa “type stripping”, karena tidak perlu source map sehingga di production benar-benar zero-cost. Tim Node benar-benar melakukannya dengan baik
• Fungsi type strip (import { stripTypeScriptTypes } from 'node:module') juga diekspos. Saat mengembangkan webapp sederhana tanpa dependensi frontend, kita bisa membuat semuanya dalam typescript lalu saat menyajikan skrip frontend cukup buang tipenya saja (contoh proyek)
• Berkat perubahan ini, perusahaan kami akhirnya bisa beralih ke Typescript. Kami mengonversi beberapa layanan ke TS sekaligus, dan sebagian lagi masih berlangsung. Hasil yang besar
• Sepertinya cara kerjanya memang hanya menghapus informasi tipe. Artinya ini mengurangi satu tahap transpile, bukan meningkatkan keamanan
  • Salah satu tujuan desain utama Typescript adalah bahwa jika hanya sintaks terkait tipe yang dihapus, hasilnya tetap merupakan file JavaScript yang valid. Kompiler TS tidak menghasilkan kode (misalnya berbeda dengan PureScript). Pemeriksaan statis dilakukan lewat type checker seperti tsc, lalu informasi tipe dihapus. Python juga mengabaikan anotasi tipe saat runtime, dan Java pun memiliki sifat bahwa sebagian informasi tipe seperti generic dihapus dari bytecode
  • Ucapan “setidaknya ini hanya mengurangi tahap transpile dan tidak meningkatkan keamanan” agak berpotensi menyesatkan. Fakta bahwa Node bisa langsung menjalankan TS memang tidak meningkatkan keamanan type-checking, tetapi type-checking tetap bisa dilakukan terpisah lewat editor atau berbagai alat lain. Dengan mendukung eksekusi TS langsung, Node menurunkan hambatan adopsi TS secara besar-besaran, dan secara tidak langsung membantu kestabilan tipe
  • Typescript tidak pernah berjanji akan menjamin peningkatan keamanan. Ini memang kesalahpahaman yang umum. TS pada dasarnya tidak punya mode atau informasi runtime, sehingga kalau type checker tidak dijalankan, kesalahan tipe yang serius pun tetap bisa dieksekusi begitu saja. Secara ketat, Typescript lebih mirip linter
  • Menurut saya bisa langsung menjalankan skrip tanpa build/transpile itu sangat praktis. Kalau perlu type-check, menjalankannya dengan tsc cocok untuk saya
  • Saya memakai setup seperti itu di proyek dengan tsx, jadi sama-sama bisa dijalankan tanpa perlu build/transpile. Saat development itu sangat berguna. Berkat --watch di tsx, saya bisa menjalankan server langsung dari source TS dan otomatis restart saat ada perubahan. Ke depan sepertinya lingkungan serupa bisa dibuat hanya dengan nodemon dan fitur bawaan Node. Kalau mau type-checking di runtime, dukungannya harus ada di level v8, dan itu nyaris pekerjaan setara menulis ulang semuanya
• Pada praktiknya ini bukan menjalankan seluruh Typescript, melainkan hanya mendukung subset tertentu. Isi judulnya bisa terasa agak berlebihan. Ada kekhawatiran perubahan seperti ini akan membuat TS dipakai hanya seperti linter, dan berbagai fitur TS yang kuat namun tidak bisa diwujudkan hanya dengan type strip bisa jadi tersisih
  • Saya penasaran fitur apa di TS yang memang tidak bisa diproses dengan strip. Selain enum, contoh yang benar-benar dipakai apa lagi?