How to Check Webpack Version

Webpack's five major versions are not drop-in replacements for each other. Each major release introduced breaking changes to configuration syntax, loader compatibility, and plugin APIs. A webpack 4 config will not work with webpack 5 without modifications, and loaders published for webpack 3 may fail silently or produce incorrect output in webpack 4+.

Beyond configuration compatibility, the webpack version affects performance. Webpack 5 introduced persistent caching, Module Federation, and improved tree-shaking that can cut build times and bundle sizes significantly compared to webpack 4. If you are debugging a slow build or investigating a bundle size regression, confirming the version is the first diagnostic step.

When version conflicts cause errors

• Loader incompatibility — `babel-loader` v8 targets webpack 4; using it with webpack 5 without updating causes silent misconfiguration.
• Plugin API mismatches — plugins that hook into the webpack compiler use an API that changed between v4 and v5. A plugin built for v4 will throw on a v5 compiler object.
• Peer dependency conflicts — tools like `webpack-dev-server`, `html-webpack-plugin`, and `mini-css-extract-plugin` all publish versions tied to specific webpack majors.
• CSS Loader schema errors — css-loader v5 and v6 have strict schema validation; a version mismatch with webpack produces the "ValidationError: Invalid options object" error.

The terminal is the fastest and most reliable way to check your webpack version. There are three commands worth knowing, each suited to a slightly different situation.

Webpack is installed locally in your project as a devDependency. The globally installed version, if any, is almost never what your build is actually using.

The project-local version (most reliable)

Your project almost certainly installs webpack as a local devDependency, not a global package. To check the version that your build scripts actually use, run `npx` or `./node_modules/.bin/webpack` directly from the project root. These commands bypass any global webpack installation and report the locally installed version.

# Most reliable — uses the local node_modules install
npx webpack --version

# Alternative path-based invocation
./node_modules/.bin/webpack --version

# Using yarn
yarn webpack --version

# Pnpm
pnpm exec webpack --version

The npm list command

`npm list webpack` queries your local `node_modules` and prints the installed version alongside its position in the dependency tree. This is useful when you want to see not just the version but also which package required webpack as a peer dependency — a common source of version conflicts when a build tool depends on a specific webpack range.

# Show webpack version in local node_modules
npm list webpack

# Show all packages in the tree that depend on webpack
npm list webpack --all

# Yarn equivalent
yarn list --pattern webpack

# Pnpm equivalent
pnpm list webpack

The globally installed version

If you installed webpack globally with `npm install -g webpack webpack-cli`, you can check that version separately. Be aware that the global version is rarely the one your project builds use — most build scripts invoke webpack through `package.json` scripts, which always resolve to the local installation.

# Global install check
webpack --version

# Or explicitly from the global path
npm list -g webpack

Your project's `package.json` file lists the webpack version range your project declared as a dependency. This is not the same as the installed version — it is the range that was specified when webpack was added, and the actual installed version may be any version within that range.

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

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

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

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

Sometimes you need to know the webpack version at build time — for example, to apply a different configuration branch depending on the major version, or to log diagnostic information in a CI pipeline. Webpack exposes its version as a property on the compiler object, and the webpack package itself exports a `version` string.

Reading the version in webpack.config.js

const webpack = require('webpack');

// The version string is available directly
console.log('Webpack version:', webpack.version);

// Use it to conditionally apply configuration
const isWebpack5 = parseInt(webpack.version, 10) >= 5;

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

Reading the version in a custom plugin or loader

Inside a webpack plugin, the compiler object carries the webpack version via `compiler.webpack.version`. This is the safest programmatic check because it reads the version of the webpack instance that invoked the plugin — not whatever version happens to be installed in `node_modules`.

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

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

Checking version in a CI environment

In a CI pipeline, the cleanest way to log the webpack version is to add a step that runs `npx webpack --version` and captures the output. This gives you the locally installed version from the exact `node_modules` that the build will use, and it appears in the pipeline log for every run — useful for debugging build failures that only appear on certain runners.

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

Understanding the differences between webpack major versions helps you decide whether your current version is appropriate for your project, and what to expect if you migrate. Here is a concise comparison of the capabilities and compatibility landscape across all five major releases.

Webpack 4 vs webpack 5 — key differences

• Persistent caching — webpack 5 caches compilation results to disk between runs; a warm cache can make rebuilds 5–10× faster than webpack 4.
• Module Federation — webpack 5 introduced Module Federation for sharing code between independently deployed frontends at runtime.
• Asset modules — webpack 5 replaces `file-loader`, `url-loader`, and `raw-loader` with built-in asset module types (`asset/resource`, `asset/inline`, etc.).
• Node.js polyfills removed — webpack 5 no longer automatically polyfills Node.js core modules. Projects that depended on polyfills for `buffer`, `path`, `stream`, etc. must add them explicitly.
• Long-term caching — webpack 5 uses deterministic chunk IDs by default, producing stable file names across builds that improve browser cache hit rates.

Version conflicts between webpack and its ecosystem are the most common source of confusing build errors. Most of these errors trace back to one of three root causes: multiple webpack copies in `node_modules`, a loader or plugin built for a different major version, or a peer dependency range mismatch.

Multiple webpack copies in node_modules

It is possible — and surprisingly common — to have more than one copy of webpack installed in your project. This happens when a dependency declares a peer dependency on webpack with a different major version range than your project uses. The result is two incompatible webpack instances, which causes plugins to silently fail or crash because they are registered against one instance but invoked by another.

# Check for multiple webpack entries in the full dep tree
npm list webpack --all

# Look for more than one unique version number in the output
# e.g., both [email protected] and [email protected] appearing
# is a sign of conflicting peer dependencies

Resolving peer dependency conflicts

When `npm list webpack --all` shows multiple webpack versions, look at which package is pulling in the older version. Update that package to a version that supports your webpack major, or use the `resolutions` field (Yarn) or `overrides` field (npm 8+) to force all packages to use a single webpack version.

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

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

Validating semver ranges

Peer dependency ranges like `"webpack": "^4 || ^5"` and `"webpack": ">=4.41.0 <6"` are valid semver expressions but easy to misread. The Semver Validator on Quasar Tools checks any version string or range expression against the Semver 2.0.0 specification — useful when you are writing a library that declares a webpack peer dependency range and want to confirm the expression is correctly formed.

Knowing your current webpack version is just the start. Managing it well — so that the version stays consistent across environments, is visible to every contributor, and is updated deliberately rather than accidentally — requires a few simple practices.

1. Pin exact versions in devDependencies — use `"webpack": "5.88.2"` rather than `"^5.88.0"` for build-critical tools. Floating ranges let patches change the installed version between `npm install` runs on different machines, making build output non-deterministic.
2. Commit your lock file — `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml` must be committed to version control. Without it, contributors and CI servers install different patch versions.
3. Log the version in CI — add a `npx webpack --version` step before every build job. The version appears in every CI log, making it easy to correlate build failures with version changes.
4. Audit dependencies after upgrades — when you update webpack, immediately run `npm list webpack --all` to confirm no secondary copies crept in, and run `npx webpack --version` to confirm the new version is what your build is using.
5. Read the migration guide before upgrading — every webpack major version has an official migration guide at `webpack.js.org`. Read it before upgrading — not after the build breaks.