Halo semuanya! Kalau kalian sering ngikutin tulisan-tulisan saya, kalian pasti tahu kalau saya itu pendukung setia PNPM. Sistem symlink globalnya yang legendaris itu benar-benar jadi penyelamat buat SSD dan manajemen monorepo saya selama ini.
Tapi hari ini, pas saya lagi seru-serunya ngoding buat ngerombak komponen di platform komunitas Koneksi (app.konxc.space), saya ngalamin momen di mana sebuah tool yang udah kita agung-agungkan kadang berasa kurang sat-set di situasi yang butuh kecepatan murni.
Ceritanya, saya lagi refactor cara render konten Markdown, nyisipin matematika pakai Katex, dan nggambar diagram lewat MermaidJS di ekosistem Qwik & Astro. Triknya saya pakai lazy dynamic imports. Eh, tiba-tiba Vite dev server kaget dan ngeluarin error log yang bikin alis berkerut: ERR_ABORTED 504 (Outdated Optimize Dep).
Kronologi Kasus: Sengkarut Cache Vite
Vite itu emang kenceng karena dia punya Dependency Pre-Bundling. Tiap kita nge-import package, Vite bakal nge-bundle modul itu jadi format ESM ke dalam node_modules/.vite dengan hash unik biar load di browser sekilat kilatnya.
Masalahnya, karena saya lumayan brutal gonta-ganti arsitektur module loader-nya, cache state Vite jadi nyangkut. Vite udah nge-generate hash baru, tapi browser tetep ngotot minta file chunk lama (pieDiagram-xxx.js). Akibatnya? Race Condition. Vite nge-blokir request basi itu pake HTTP 504.
Solusi “Nuke dari Orbit”
Kalau mentok masalah infrastruktur cache abal-abal begini, bagi saya cuma ada satu jalan ninja: Nuke dari Orbit. Hapus paksa folder node_modules dan .astro.
rm -rf .astro node_modulesPuas rasanya ngeliat proyek balik ke kondisi suci bin bersih. Tapi… doom comes right after. Kita harus unduh dan ekstrak ribuan dependensi dari awal sebelum dev server bisa nyala lagi. Total ada 1172 package di project saya ini.
Masuknya Bun ke Gelanggang
Sebenarnya ya, nggak masalah sama sekali kalau kita tetap pakai PNPM buat urusan ini. Ya udahlah, tungguin aja terminal lewat symlink routine-nya beberapa puluh detik. Toh ini cuma jalan di lingkungan development lokal. Santai aja.
Kecepatan resolution & instalasi dependensi ini mungkin baru bakal kerasa jadi pain point atau metrik krusial kalau konteksnya udah jalan di pipeline CI/CD cloud (meskipun error 504 ini pun jarang langsung ngefek ke stage deliver/preview karena sifatnya yg lebih sering muncul pas lagi hot-reload lokal).
Tapi… karena tangan saya iseng, saya mutusin buat nyuruh Bun maju ke medan tempur. Iya, saya pakai Bun murni cuma as a package manager buat ngeksekusi bun i, ngegantiin pnpm install.
Dan jujur aja, hasilnya bener-bener gila.
bun install v1.3.2 (b131639c)
[11.48s] migrated lockfile from pnpm-lock.yaml
$ husky
+ @astrojs/check@0.9.5
...
+ typescript@5.9.3
1172 packages installed [13.20s]Cuma 13.2 detik, cuy! Dalam kedipan mata, Bun baca pnpm-lock.yaml, konversi lockfile, download ratusan megabyte, ngekstrak 1172 package langsung nancep ke dalam disk, dan sempat-sempatnya dia ngerun skrip postinstall Husky dengan sukses.
Bukan Apple to Apple, Tapi Tetap Mindblowing
Loh, lantas apa kita harus bakar PNPM dan buru-buru hijrah ke Bun?
Wah, santai bang jago, tahan dulu.
Saya sadar banget, narik perbandingan rivalitas antara Bun dan PNPM itu sebenarnya bukan sesuatu yang apple to apple. Keduanya punya peruntukan spesifik, lahir dari kerangka pikiran yang beda, dan menguasai ceruk (niche) dunianya masing-masing. Bun itu ekosistem utuh lintas fungsi (Runtime, Bundler, Test Runner, PM) yang di-desain pakai low-level OS API dan bahas Zig buat memeras titik puncak kecepatan komputasi. Sedangkan PNPM mengukir namanya di mahakarya stabilitas struktur dependensi ketat dan efisiensi memori raksasa.
Opsi pakai Bun di skala project ini adalah sebuah pertimbangan yang cukup powerful, itupun dengan catatan: tim, operasional, dan ekosistem proyek kalian nggak keberatan buat di-gas ke arah adopsi mekanisme/mesin POC yang terus-terusan merangsek jadi bleeding-edge ini.
Tapi faktanya, kalau tim (ataupun kalian sendiri) mau tetap berdiri teguh pakai PNPM itu sangat tidak masalah! PNPM masihlah raja mutlak buat monorepo, integritas instalasi ruang penyimpanan jangka panjang yang ramah, dan standardisasi ketat yang nggak bikin dev server tiba-tiba “mencret” gara-gara inkonsistensi.
Kesimpulan Harian Saya
Buat saya pribadi dari petualangan ngoding hari ini: Menyimpan Bun di dalam mesin local saya ternyata jadi Quality of Life yang sangat menyenangkan. Ia seakan menjadi cheat code.
Kapanpun eksperimen gagal, cache korup, dan saya terpaksa harus ngeluarin jurus “Nuke node_modules”, bun i bikin downtime nunggu saya dari hitungan “bisa sambil bikin kopi” menyusut jadi hitungan “baru tarik nafas udah kelar”.
Kecepatan ini bikin iterasi development jauh lebih ngalir dan enjoy. Jadi, buat kalian ksatria Trial & Error, pernah ngalamin momen kudu nge-BOM node_modules nggak? Kasih tahu ya kalian masuk team nungguin PNPM santay atau sikat brutal pakai Bun!
Comments