Migrasi aplikasi TypeScript dari Node.js ke Bun – Beragampengetahuan

Saya sudah lama ingin melihat beberapa runtime JavaScript alternatif. Apa yang menahan saya adalah kompatibilitas npm. Saya ingin dapat menjalankan kode saya di runtime selain Node.js dan masih dapat menggunakan paket npm. Saya telah menggunakan ts-node untuk waktu yang lama; itulah yang saya dapatkan saat membuat aplikasi konsol apa pun.

Pada artikel ini, saya akan membahas betapa mudahnya mem-porting aplikasi TypeScript dari Node.js ke Bun.

Lompat ke depan:

Siapkan aplikasi ts-node

Saya memiliki blog teknis berdasarkan Docusaurus. Saat build Docusaurus selesai, skrip pasca-pemrosesan dijalankan untuk melakukan tindakan berikut:

• memperbarui sitemap.xml termasuk lastmod tanggal, berdasarkan tanggal komit git, dan memotong jumlah entri dalam file
• Patch file HTML untuk menggunakan Cloudinary sebagai CDN gambar untuk gambar Grafik Terbuka

Skrip ini diimplementasikan sebagai aplikasi konsol ts-node sederhana.Untuk alasan sejarah disebut trim-xml (awalnya hanya memotong file sitemap.xml dokumen). Itu bukan nama yang sangat bagus, tapi saya tidak berencana mengubahnya sekarang.Karena blog adalah open source, Anda dapat melihat kodenya trim-xml Di Sini.

Kami tertarik untuk mem-porting aplikasi ini dari ts-node ke Bun. Aplikasi memiliki beberapa dependensi, jadi kompatibilitas npm penting bagi kami. Mari kita lihat bagaimana kelanjutannya.

instal roti

Saya menginstal Bun di mesin Ubuntu saya dengan perintah berikut:

curl -fsSL  | bash

Output yang dihasilkan terlihat seperti ini:

>bun was installed successfully to ~/.bun/bin/bun

Added "~/.bun/bin" to $PATH in "~/.zshrc"

To get started, run:

 exec /usr/bin/zsh
  bun --help

Lekukan yang tidak konsisten pada keluaran membuat saya sedikit aneh, tapi saya yakin itu hanya masalah pemformatan. Saya mengirimkan PR untuk memperbaikinya. Saat saya menjalankan perintah yang disarankan, Bun terlihat bahagia dan sehat.

Migrasikan instalasi dari Yarn ke Bun

Dengan Bun, saya dapat mem-porting aplikasi. Saya membuka (seperti yang saya katakan, nama buruk) trim-xml direktori dan memicu instal dependensi menggunakan bun install:

cd trim-xml
bun install

Ini menghasilkan output berikut:

bun install v0.5.7 (5929daee)
 + @types/[email protected]
 + [email protected]
 + [email protected]
 + [email protected]

 5 packages installed [2.34s]

yang baru lagi bun.lockb File muncul di direktori di sebelah package.json dokumen.

Meskipun saya tidak dapat menemukan dokumentasi pendukung, saya menduga ini setara dengan Bun package-lock.json atau yarn.lock dokumen. Ini file biner, jadi tidak bisa dibaca.Namun, saya menemukan proyek ini yang memungkinkan Anda membacabun.lockb file, sepertinya solusi yang berguna untuk masalah ini.

Untuk menghindari kebingungan, saya juga menghapus yarn.lock dokumen. Hore – Saya telah menginstal sesuatu! Dan, cukup cepat! Apa berikutnya?

beralih dari @types/node tiba bun/types

Ketika saya melihat output dari penginstalan, saya menyadarinya @types/node Paket sudah diinstal.ini @types/node Paket berisi definisi TypeScript untuk runtime Node.js. Mengingat rencana saya untuk menggunakan Bun, sepertinya saya tidak membutuhkan ini. Namun, saya mungkin membutuhkan sesuatu yang mewakili tipe runtime Bun (btw, saya membayangkan ini sangat mirip dengan tipe runtime Node.js).

Saya melihat sekilas dokumentasi Bun dan menemukan bun/types mengemas.Saya menambahkannya ke proyek saya saat menghapus @types/nodeDan ts-node:

bun remove @types/node
bun remove ts-node
bun add bun-types

Berikut tampilan outputnya:

 bun remove v0.5.7 (5929daee)
 - @types/node

 1 packages removed [3.00ms]
bun remove v0.5.7 (5929daee)
 - ts-node

 1 packages removed [843.00ms]
bun add v0.5.7 (5929daee)

 installed [email protected]


 1 packages installed [1.97s]

Dokumen juga mengatakan untuk menambahkan kode berikut ke file tsconfig.json atau jsconfig.json dokumen:

{
  "compilerOptions": {
    "lib": ["ESNext"],
    "module": "esnext",
    "target": "esnext",
    // "bun-types" is the important part
    "types": ["bun-types"]
  }
}

Saya menyesuaikan keberadaan saya tsconfig.json dengan berkas di atas. Untuk aplikasi konsol saya, ini berarti perubahan berikut:

  {
    "compilerOptions": {
-      "target": "ES2022",
+      "target": "esnext",
-      // "lib": [],
+      "lib": ["ESNext"],
-      "module": "NodeNext",
+      "module": "esnext",
-      // "types": [],
+      "types": ["bun-types"],
    },
  }

menangani moduleResolution roti isi kukus

Pada titik ini, saya pikir saya dapat menjalankan aplikasi. Namun, ketika saya menjelajah di VS Code, saya melihat bahwa saya memiliki banyak kesalahan:

Pesan kesalahan menunjukkan bahwa saya perlu secara eksplisit menyatakan bahwa saya ingin menggunakan algoritma resolusi modul Node.js. Kami menggunakan Bun, tetapi kami mem-porting aplikasi Node, jadi ini masuk akal.

Untuk memperbaikinya, saya melakukan tsconfig.json dokumen:

  {
    "compilerOptions": {
-      // "moduleResolution": "node",
+      "moduleResolution": "nodenext",
    },
  }

Dengan perubahan ini, kesalahan penguraian modul… teratasi. (Maaf!)

Menggunakan API arsip Bun

Bahkan setelah menyelesaikan kesalahan penguraian modul, saya masih mendapatkan kesalahan lain.kali ini mereka tentang fs.promises API:

Sepertinya versi Bun yang saya gunakan tidak mendukung API itu.Ketika saya menggali kode saya, saya menyadari bahwa saya sedang menggunakan fs.promises API ada di beberapa tempat. Saya menggunakannya dengan cara berikut:

• await fs.promises.readdir
• await fs.promises.readFile
• await fs.promises.writeFile

saya bisa mengganti fs.promises.readFile Dan fs.promises.writeFile Setara Bun Bun.file(path).text()Dan Bun.write(path, content)masing-masing:

- `await fs.promises.readFile`
+ `await Bun.file(path).text()`
- `await fs.promises.writeFile(path, content)`
+ `await Bun.write(path, content)`

Namun, sepertinya tidak ada Bun yang setara dengan fs.promises.readdirjadi saya menggunakan API Node.js sinkron:

- `await fs.promises.readdir`
+ `fs.readdirSync(path)`

Pada akhirnya, kode tersebut bebas dari kesalahan (setidaknya dalam Kode VS, sejauh menyangkut TypeScript). Namun, saya belum menjalankan aplikasi untuk melihat apakah itu benar-benar berfungsi.

klarifikasi tentang fs.promises API

Saat memecahkan masalah bug API fs.promises, saya men-tweet tentang temuan saya. Jarred Sumner (yang bekerja di Bun) cukup baik untuk berbagi Itu fs.promises API diimplementasikan, tetapi jenisnya tidak, pada saat penulisan:

Jarred Sumner tweeted: “Itu ada, tapi sepertinya tipenya sudah usang. Saya katakan karena, sebenarnya semua async disinkronkan dengan node:fs, itu hanya dibungkus dengan Promise jika Anda menggunakan fs createReadStream / fs.createWriteStream atau Bun. file(path).stream() itu akan bersamaan/asinkron/Twitter”

Jenisnya memang ada, tapi sepertinya jenisnya sudah ketinggalan zaman.Saya katakan karena, sebenarnya untuk node:fs semua async disinkronkan, itu hanya dibungkus dengan Promise

menjalankan aplikasi

Sebelum menjalankan aplikasi, saya perlu melakukan satu hal lagi:

-    "start": "ts-node index.ts"
+    "start": "bun index.ts"

ya, perbarui start dalam naskah package.json menggunakan bun mengganti ts-node.

sekarang saya bisa menggunakan bun start Memesan:

Loading /home/john/code/github/blog.johnnyreilly.com/blog-website/build/sitemap.xml
Reducing 526 urls to 512 urls

Hal positif pertama yang saya lihat adalah sepertinya saya menjalankan kode. Ya!

Program tersebut juga tampaknya dijalankan secara instan, yang tampaknya mengejutkan. Saya pikir Baozi akan cepat, tapi saya tidak menyangka akan terlalu cepat! Juga, itu tidak memiliki banyak pesan log yang saya harapkan. Saya mengharapkan untuk melihat sekitar 1000 pesan log. Sesuatu yang salah.

lantai atas await dan roti

masalahnya adalah milikku main Fungsi tidak sinkron.Namun, karena dukungan untuk tingkat atas await Tidak tersedia di Node.js ketika saya awalnya menulis kode, saya menelepon main berjalan secara sinkron. Untungnya, Node tidak mengeluhkan hal ini, dan program berjalan seperti yang diharapkan.

Namun, Bun tampaknya menghargai kenyataan itu main asinkron.Itu sebabnya tampaknya dieksekusi begitu cepat; itu tidak menunggu main Metode ini selesai sebelum diakhiri.

Jujur, Bun berperilaku tepat di sini; kodenya tidak menunjukkan bahwa dia tertarik untuk menunggu main berfungsi untuk menyelesaikan. Namun, ternyata menunggu adalah perilaku yang diinginkan.Untuk memperbaikinya, saya bisa menggunakan tingkat atas await.

Jadi, saya benar index.ts dokumen:

- main();
+ await main();

Saya mulai mendapatkan pesan log yang diharapkan; program tampaknya bekerja seperti yang diharapkan.

Tindakan dan Roti GitHub

Saya sekarang dapat menjalankan aplikasi secara lokal. Tapi saya ingin menjalankannya di Tindakan GitHub.Saya hanya perlu menambahkan setup-bun action ke dalam alur kerja saya, jadi bun akan tersedia di lingkungan GitHub Actions:

- name: Setup bun 🔧
  uses: oven-sh/[email protected]
  with:
    bun-version: latest

Perbandingan Performa: Bun vs. ts-node

Saya berharap Bun lebih cepat dari ts-node. Mari jalankan aplikasi di GitHub Actions menggunakan ts-node dan bandingkan dengan menjalankannya dengan Bun:

Jalankan aplikasi di Tindakan GitHub menggunakan ts-node:

Post processing finished in 17.09 seconds
Done in 19.52s.

Jalankan aplikasi di Tindakan GitHub menggunakan Bun:

Post processing finished in 12.367 seconds
Done in 12.72s.

Saya belum melakukan tolok ukur formal, tetapi sepertinya Bun sekitar 50% lebih cepat daripada ts-node untuk kasus penggunaan ini. Tidak apa-apa.

Perlu juga diperluas tentang bagaimana itu rusak. Anda akan melihat dua entri log di log di atas:

1. “Postprocessing” mencerminkan waktu yang diperlukan untuk menjalankan main Fungsi
2. “Selesai” mencerminkan berlari bun perintah ujung ke ujung

Apa yang bisa kita pelajari darinya? Pertama, kode membutuhkan waktu 17 detik untuk dijalankan di ts-node dan 12 detik dengan Bun. Hasilnya, Bun mengeksekusi sekitar 40% lebih cepat saat menjalankan kode.

Butuh 19 detik untuk menjalankan perintah end-to-end dengan ts-node dan 14 detik dengan Bun. Jadi kecepatan eksekusi ujung ke ujung Bun sekitar 50% lebih cepat. Ada dua bagian untuk ini: waktu yang diperlukan untuk mengkompilasi kode dan waktu yang diperlukan untuk memulai. Selain itu, kami menggunakan ts-node untuk pengecekan tipe – jika dihentikan, itu akan membuat perbedaan.

Tetapi jika Anda melihat perbedaan antara runtime end-to-end dan runtime kode menggunakan Bun, itu hanya 0,353 detik. Demikian pula, waktu ts-node adalah 2,43 detik. Akibatnya, ts-node sekitar 6,5 kali lebih lambat saat startup. Itu perbedaan besar; tidak mungkin semua ini adalah kompilasi TypeScript; Node.js pada dasarnya lebih lambat dibandingkan dengan Bun.

Kesimpulannya

Bermigrasi dari ts-node ke Bun adalah proses yang sangat sederhana. Saya bisa melakukannya dalam beberapa jam. Saya dapat menjalankan aplikasi secara lokal dan di GitHub Actions. Selain itu, saya dapat menjalankan aplikasi dalam waktu yang lebih singkat.

Ini semua membuat saya merasa sangat positif tentang Bun. Saya berharap untuk menggunakannya lebih banyak di masa mendatang.