Lompat ke konten
Kembali ke modul

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

  1. Client-nya membaca package.json untuk melihat apa yang kamu minta.
  2. Ia menentukan versi tepat untuk setiap package, langsung maupun transitif — ini disebut resolution.
  3. Ia menulis versi-versi tepat itu ke sebuah lockfile supaya install berikutnya identik.
  4. Ia mengunduh setiap package dan mengekstraknya ke node_modules/.
  5. 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.json plus 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_modules sebelumnya di jalur ini.
  • Hapus dengan santai. rm -rf node_modules && bun install memang benar-benar memperbaiki sekelompok masalah, dan biayanya cuma waktu.

dependencies versus devDependencies

dependenciesdevDependencies
Dibutuhkan saat runtimeYaTidak
Di-install di productionYaTidak
Contohnext, react, lucide-reactvitest, eslint, typescript
Perintahbun add xbun 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

bash
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-cli

Tugas 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.