Node.js, Package, dan Ekosistemnya · 2/7
Package manager: npm, pnpm, bun
Apa yang sebenarnya terjadi di disk saat "install package", dan kenapa di sini kita pakai bun.
Baca 25 menit
Setelah pelajaran ini kamu bisa
- Menyebutkan apa yang sebenarnya dilakukan proses install package pada disk-mu
- Menjelaskan bedanya dependencies dan devDependencies
- Menjelaskan kenapa jangan pernah commit node_modules dan jangan mengeditnya
- Memakai perintah yang kamu butuhkan sehari-hari
Package adalah kode orang lain, dipublikasikan ke sebuah registry supaya bisa kamu pakai. Package manager mengunduhnya, beserta semua yang dibutuhkannya, lalu menaruhnya di tempat yang bisa ditemukan import-mu.
Registry-nya adalah npm — sebuah situs dan API yang menyimpan lebih dari dua juta package. npm juga nama client aslinya, dan dari situlah kebingungannya mulai. pnpm dan bun adalah client berbeda yang mengunduh dari registry yang sama.
Apa yang sebenarnya terjadi di disk
- Client-nya membaca
package.jsonuntuk melihat apa yang kamu minta. - Ia menentukan versi tepat untuk setiap package, langsung maupun transitif — ini disebut resolution.
- Ia menulis versi-versi tepat itu ke sebuah lockfile supaya install berikutnya identik.
- Ia mengunduh setiap package dan mengekstraknya ke
node_modules/. - Ia menjalankan script install apa pun yang dideklarasikan package-package itu.
node_modules
- Jangan pernah commit. Ukurannya besar, spesifik per mesin, dan bisa dibuat ulang sepenuhnya dari
package.jsonplus lockfile. Tempatnya di.gitignore— cek milik proyek ini dan kamu akan menemukannya di sana. - Jangan pernah edit. Perubahanmu hilang di install berikutnya. Kalau kamu harus mengubah perilaku sebuah dependency, pakai alat patch atau fork.
- Tapi bacalah. Itu kode sumber sebenarnya dari setiap library yang kamu pakai. Saat dokumentasinya tidak jelas, jawabannya ada di sana — kamu sudah membaca dokumentasi Next.js dari
node_modulessebelumnya di jalur ini. - Hapus dengan santai.
rm -rf node_modules && bun installmemang benar-benar memperbaiki sekelompok masalah, dan biayanya cuma waktu.
dependencies versus devDependencies
| dependencies | devDependencies | |
|---|---|---|
| Dibutuhkan saat runtime | Ya | Tidak |
| Di-install di production | Ya | Tidak |
| Contoh | next, react, lucide-react | vitest, eslint, typescript |
| Perintah | bun add x | bun add -D x |
Ujinya sederhana: apakah aplikasi yang sedang berjalan membutuhkannya? Test runner tidak. Library UI iya. Menaruh alat build di dependencies membuat image production-mu gemuk; menaruh library runtime di devDependencies merusak production padahal jalan sempurna di mesinmu.
Perintah-perintahnya
bun install # install everything in package.json
bun add zod # add a runtime dependency
bun add -D vitest # add a development dependency
bun remove zod # remove it, and update the lockfile
bun update # move versions up, within the ranges allowed
bun outdated # what is behind, without changing anything
bun run dev # run a script from package.json
bunx shadcn@latest add # run a package's CLI without installing it
# The npm equivalents, which you will still see everywhere:
npm install / npm i
npm install --save-dev vitest
npm uninstall zod
npx some-cliTugas praktik
Di proyek ini, jalankan ls node_modules | wc -l untuk menghitung package yang ter-install. Lalu jalankan cat package.json dan hitung yang benar-benar kamu minta. Jelaskan selisihnya dalam satu kalimat. Terakhir, jalankan ls node_modules/next/dist/docs — itu kode sumber sebuah dependency, bisa dibaca dan berguna.
Hasil yang diharapkan
Ratusan ter-install, sekitar dua puluh yang diminta — sisanya transitif.