Cara Memeriksa Versi Webpack: Terminal, package.json dan Config

Lima versi mayor webpack bukanlah pengganti drop-in satu sama lain. Setiap rilis mayor memperkenalkan perubahan yang merusak pada sintaks konfigurasi, kompatibilitas loader, dan API plugin. Config webpack 4 tidak akan bekerja dengan webpack 5 tanpa modifikasi, dan loader yang dipublikasikan untuk webpack 3 bisa gagal secara diam-diam atau menghasilkan output yang salah di webpack 4+.

Di luar kompatibilitas konfigurasi, versi webpack memengaruhi performa. Webpack 5 memperkenalkan caching persisten, Module Federation, dan tree-shaking yang ditingkatkan yang dapat memangkas waktu build dan ukuran bundle secara signifikan dibandingkan webpack 4. Jika Anda sedang men-debug build yang lambat atau menyelidiki regresi ukuran bundle, mengonfirmasi versi adalah langkah diagnostik pertama.

Ketika konflik versi menyebabkan error

• Ketidakcocokan loader - `babel-loader` v8 menargetkan webpack 4; menggunakannya dengan webpack 5 tanpa memperbarui menyebabkan kesalahan konfigurasi secara diam-diam.
• Ketidakcocokan API plugin - plugin yang mengaitkan diri ke compiler webpack menggunakan API yang berubah antara v4 dan v5. Plugin yang dibuat untuk v4 akan error pada objek compiler v5.
• Konflik peer dependency - alat seperti `webpack-dev-server`, `html-webpack-plugin`, dan `mini-css-extract-plugin` menerbitkan versi yang terikat pada versi mayor webpack tertentu.
• Error skema css-loader - css-loader v5 dan v6 memiliki validasi skema yang ketat; ketidakcocokan versi dengan webpack menghasilkan error "ValidationError: Invalid options object".

Terminal adalah cara tercepat dan paling andal untuk memeriksa versi webpack Anda. Ada tiga perintah yang patut diketahui, masing-masing cocok untuk situasi yang sedikit berbeda.

Webpack terinstal secara lokal di proyek Anda sebagai devDependency. Versi yang terinstal secara global, jika ada, hampir tidak pernah menjadi yang benar-benar digunakan build Anda.

Versi lokal proyek (paling andal)

Proyek Anda hampir pasti menginstal webpack sebagai devDependency lokal, bukan paket global. Untuk memeriksa versi yang benar-benar digunakan skrip build Anda, jalankan `npx` atau `./node_modules/.bin/webpack` langsung dari root proyek. Perintah-perintah ini melewati instalasi webpack global apa pun dan melaporkan versi yang terinstal secara lokal.

# Paling andal - menggunakan instalasi node_modules lokal
npx webpack --version

# Invokasi alternatif berbasis jalur
./node_modules/.bin/webpack --version

# Menggunakan yarn
yarn webpack --version

# Pnpm
pnpm exec webpack --version

Perintah npm list

`npm list webpack` menanyakan `node_modules` lokal Anda dan mencetak versi yang terinstal beserta posisinya di pohon dependensi. Ini berguna ketika Anda ingin melihat bukan hanya versinya tetapi juga paket mana yang mengharuskan webpack sebagai peer dependency — sumber umum konflik versi ketika alat build bergantung pada rentang webpack tertentu.

# Menampilkan versi webpack di node_modules lokal
npm list webpack

# Menampilkan semua paket di pohon yang bergantung pada webpack
npm list webpack --all

# Padanan yarn
yarn list --pattern webpack

# Padanan pnpm
pnpm list webpack

Versi yang terinstal global

Jika Anda menginstal webpack secara global dengan `npm install -g webpack webpack-cli`, Anda dapat memeriksa versi itu secara terpisah. Ketahuilah bahwa versi global jarang menjadi yang digunakan build proyek Anda — sebagian besar skrip build memanggil webpack melalui skrip `package.json`, yang selalu menyelesaikan ke instalasi lokal.

# Pemeriksaan instalasi global
webpack --version

# Atau secara eksplisit dari jalur global
npm list -g webpack

File `package.json` proyek Anda mencantumkan rentang versi webpack yang dideklarasikan proyek sebagai dependensi. Ini tidak sama dengan versi yang terinstal — itu adalah rentang yang ditentukan saat webpack ditambahkan, dan versi yang benar-benar terinstal bisa berupa versi apa pun dalam rentang tersebut.

{
  "devDependencies": {
    "webpack": "^5.88.0",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^4.15.1"
  }
}

# Di package-lock.json (npm)
grep '"webpack"' package-lock.json | head -5

# Di yarn.lock
grep 'webpack@' yarn.lock | head -5

# Di pnpm-lock.yaml
grep 'webpack' pnpm-lock.yaml | head -10

Kadang Anda perlu tahu versi webpack pada saat build — misalnya, untuk menerapkan cabang konfigurasi yang berbeda sesuai versi mayor, atau untuk mencatat informasi diagnostik di pipeline CI. Webpack mengekspos versinya sebagai properti pada objek compiler, dan paket webpack sendiri mengekspor string `version`.

Membaca versi di webpack.config.js

const webpack = require('webpack');

// String versi tersedia secara langsung
console.log('Webpack version:', webpack.version);

// Gunakan untuk menerapkan konfigurasi secara kondisional
const isWebpack5 = parseInt(webpack.version, 10) >= 5;

module.exports = {
  // ...
  plugins: [
    isWebpack5
      ? new webpack.ids.DeterministicModuleIdsPlugin()
      : new webpack.HashedModuleIdsPlugin(),
  ],
};

Membaca versi di plugin atau loader kustom

Di dalam plugin webpack, objek compiler membawa versi webpack melalui `compiler.webpack.version`. Ini adalah pemeriksaan programatik paling aman karena membaca versi instance webpack yang memanggil plugin — bukan versi apa pun yang kebetulan terinstal di `node_modules`.

class MyPlugin {
  apply(compiler) {
    // compiler.webpack tersedia di webpack 5+
    const version = compiler.webpack?.version ?? webpack.version;
    console.log('Running on webpack', version);

    compiler.hooks.done.tap('MyPlugin', (stats) => {
      // Build complete
    });
  }
}

Memeriksa versi di lingkungan CI

Di pipeline CI, cara terbersih untuk mencatat versi webpack adalah menambahkan langkah yang menjalankan `npx webpack --version` dan menangkap outputnya. Ini memberi Anda versi yang terinstal lokal dari `node_modules` persis yang akan digunakan build, dan muncul di log pipeline untuk setiap eksekusi — berguna untuk men-debug kegagalan build yang hanya muncul di runner tertentu.

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: '20'
  - run: npm ci
  - name: Log webpack version
    run: npx webpack --version
  - name: Build
    run: npm run build

Memahami perbedaan antara versi mayor webpack membantu Anda memutuskan apakah versi Anda saat ini sesuai untuk proyek, dan apa yang diharapkan jika bermigrasi. Berikut perbandingan ringkas kemampuan dan lanskap kompatibilitas di kelima rilis mayor.

Webpack 4 vs webpack 5 - perbedaan utama

• Cache persisten - webpack 5 meng-cache hasil kompilasi ke disk antar eksekusi; cache hangat dapat membuat rebuild 5-10× lebih cepat daripada webpack 4.
• Module Federation - webpack 5 memperkenalkan Module Federation untuk berbagi kode antara frontend yang di-deploy secara independen saat runtime.
• Modul aset - webpack 5 menggantikan `file-loader`, `url-loader`, dan `raw-loader` dengan tipe modul aset bawaan (`asset/resource`, `asset/inline`, dll.).
• Polyfill Node.js dihapus - webpack 5 tidak lagi otomatis mem-polyfill modul inti Node.js. Proyek yang bergantung pada polyfill untuk `buffer`, `path`, `stream`, dll. harus menambahkannya secara eksplisit.
• Caching jangka panjang - webpack 5 menggunakan ID chunk deterministik secara default, menghasilkan nama file yang stabil antar build yang meningkatkan tingkat hit cache peramban.

Konflik versi antara webpack dan ekosistemnya adalah sumber paling umum dari error build yang membingungkan. Sebagian besar error ini bermula dari salah satu dari tiga akar penyebab: beberapa salinan webpack di `node_modules`, loader atau plugin yang dibuat untuk versi mayor berbeda, atau ketidakcocokan rentang peer dependency.

Beberapa salinan webpack di node_modules

Sangat mungkin — dan cukup umum terjadi — memiliki lebih dari satu salinan webpack yang terinstal di proyek Anda. Ini terjadi ketika sebuah dependensi mendeklarasikan peer dependency pada webpack dengan rentang versi mayor yang berbeda dari yang digunakan proyek Anda. Hasilnya adalah dua instance webpack yang tidak kompatibel, yang menyebabkan plugin gagal diam-diam atau crash karena terdaftar pada satu instance tetapi dipanggil oleh yang lain.

# Memeriksa beberapa entri webpack di pohon dependensi penuh
npm list webpack --all

# Cari lebih dari satu nomor versi unik di output
# misalnya, munculnya [email protected] dan [email protected] sekaligus
# adalah tanda peer dependency yang berkonflik

Menyelesaikan konflik peer dependency

Ketika `npm list webpack --all` menunjukkan beberapa versi webpack, lihat paket mana yang menarik versi lama. Perbarui paket tersebut ke versi yang mendukung versi mayor webpack Anda, atau gunakan field `resolutions` (Yarn) atau `overrides` (npm 8+) untuk memaksa semua paket menggunakan satu versi webpack.

{
  "overrides": {
    "webpack": "^5.88.0"
  }
}

{
  "resolutions": {
    "webpack": "^5.88.0"
  }
}

Memvalidasi rentang semver

Rentang peer dependency seperti `"webpack": "^4 || ^5"` dan `"webpack": ">=4.41.0 <6"` adalah ekspresi semver yang valid tetapi mudah salah dibaca. Validator semver dari Aback Tools memeriksa string versi atau ekspresi rentang apa pun terhadap spesifikasi Semver 2.0.0 — berguna ketika Anda menulis library yang mendeklarasikan rentang peer dependency webpack dan ingin memastikan ekspresinya terbentuk dengan benar.

Mengetahui versi webpack Anda saat ini hanyalah awal. Mengelolanya dengan baik — agar versi tetap konsisten di berbagai lingkungan, terlihat oleh setiap kontributor, dan diperbarui secara disengaja bukan secara tak sengaja — membutuhkan beberapa praktik sederhana.

1. Kunci versi tepat di devDependencies - gunakan `"webpack": "5.88.2"` alih-alih `"^5.88.0"` untuk alat yang kritis bagi build. Rentang mengambang memungkinkan patch mengubah versi yang terinstal antara eksekusi `npm install` di mesin yang berbeda, membuat output build tidak deterministik.
2. Commit lock file Anda - `package-lock.json`, `yarn.lock`, atau `pnpm-lock.yaml` harus di-commit ke version control. Tanpanya, kontributor dan server CI menginstal versi patch yang berbeda.
3. Catat versi di CI - tambahkan langkah `npx webpack --version` sebelum setiap job build. Versinya muncul di setiap log CI, memudahkan mengaitkan kegagalan build dengan perubahan versi.
4. Audit dependensi setelah peningkatan - saat memperbarui webpack, segera jalankan `npm list webpack --all` untuk memastikan tidak ada salinan sekunder yang masuk, dan `npx webpack --version` untuk memastikan versi baru adalah yang digunakan build Anda.
5. Baca panduan migrasi sebelum meningkatkan - setiap versi mayor webpack punya panduan migrasi resmi di `webpack.js.org`. Baca sebelum meningkatkan — bukan setelah build rusak.