cloudparts

webpack

The JavaScript bundler built around code splitting, loaders and plugins: written in JavaScript, highly configurable, and still downloaded tens of millions of times a week.

OpenJS · Impact
What it is
Bundlers and dev servers
Used for
Build tools
Type
Open source
Made by
OpenJS Foundation
Foundation
OpenJS Foundation, impact, joined March 2019. A founding project, from the JS Foundation it joined in 2016. Part of the Linux Foundation
License
MIT
Facts checked
28 October 2026
Website Source code

What it is

webpack is a static module bundler. Starting from one or more entry points, it follows every import and require to build a dependency graph, then writes the modules into one or more bundles to serve. Out of the box it understands JavaScript, JSON and WebAssembly. Anything else goes through loaders, functions that turn a file into modules (babel-loader for modern syntax, ts-loader for TypeScript), while plugins hook into the whole compilation for jobs such as minifying, injecting environment variables or writing HTML. Since webpack 4 a config file is optional: it bundles ./src/index.js into ./dist/main.js, and mode switches between development and production defaults.

webpack 5, released on October 10, 2020, is still the current major; version 5.112 came out in October 2026. It added an opt-in persistent file-system cache, asset modules, and Module Federation, which lets separately built and deployed apps load modules from each other at run time. It also stopped polyfilling Node.js core modules for the browser. The 2026 roadmap moves common plugins into the core: native CSS and HTML entry points as experiments options, TypeScript tsconfig paths (shipped in 5.105) and, later, TypeScript without a loader, ahead of a webpack 6 that has no release date.

Its position has changed. Faster tools have taken over new projects: Vite, which builds with Rolldown since Vite 8, now has more than three times webpack’s npm downloads, and Next.js 16 (October 2025) made Turbopack its default and kept webpack behind a --webpack flag. ByteDance’s Rspack, written in Rust, implements webpack’s API and runs most of its loaders and plugins, as a faster drop-in replacement. webpack itself is maintained mostly by volunteers. In the week to October 27, 2026 it was still downloaded about 63 million times from npm, against about 212 million for Vite.

Why teams pick it

  • Fine control over output: code splitting at every dynamic import(), splitChunks rules for shared code, and content-hashed file names for long-term caching
  • Module Federation for loading code from separately deployed builds at run time
  • A huge ecosystem of loaders and plugins, and a stable API that Rspack also implements, so large existing setups keep working
  • Persistent caching makes rebuilds of large projects much faster after the first one

Watch out for

  • Written in JavaScript: cold builds and dev-server start-up are slower than Rust and Go bundlers such as Rspack, Rolldown and esbuild
  • Configuration grows quickly; loaders, plugins and their interactions are a common source of hard-to-debug builds
  • The dev server bundles the app before serving it, unlike Vite, which serves source modules on demand
  • Volunteer-maintained with no full-time team, and frameworks such as Next.js have moved their defaults to other bundlers

Alternatives

What all bundlers and dev servers have in common →Compare side by side →
ViteOpen sourceThe dev server and build tool most JavaScript frameworks now build on: native ES modules with instant HMR while you code, a Rolldown bundle for production.RolldownOpen sourceA JavaScript bundler written in Rust that keeps Rollup’s plugin API at esbuild’s speed; the bundler inside Vite since Vite 8.

How it fits with other technologies

A production config with caching, a split vendor chunk and native CSS · js

// webpack.config.js
import path from 'node:path';

export default {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(import.meta.dirname, 'dist'),
    filename: '[name].[contenthash].js',   // new hash only when the content changes
    clean: true,
  },
  module: {
    rules: [{ test: /\.ts$/, use: 'ts-loader' }],   // loaders turn other files into modules
  },
  resolve: { extensions: ['.ts', '.js'] },
  experiments: { css: true },   // import './app.css' without css-loader or plugins
  cache: { type: 'filesystem' },   // reuse work between builds
  optimization: {
    splitChunks: { chunks: 'all' },   // node_modules code goes into its own chunk
  },
};

// $ npx webpack
// every dynamic import('./chart.ts') in the source also becomes its own chunk

See it in a real stack

No architecture uses webpack yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2012–2026

Tobias Koppers came to JavaScript from Java, where Google Web Toolkit could split an application into pieces loaded on demand. He missed that in JavaScript tooling, proposed it to the modules-webmake bundler, and when the change did not go forward wrote his own bundler in 2012. Instagram’s front-end team found an early version and adopted it, partly for code splitting, and Pete Hunt’s talk about it at OSCON in 2014 brought it a wide audience.

webpack 1.0 came out in February 2014. It followed imports itself, used loaders to bring CSS, images and other files into the same dependency graph, and split code at chosen points. webpack 4 (February 2018) introduced mode and made configuration optional, and webpack 5 (October 2020) added persistent caching and Module Federation. The project joined the JS Foundation at its launch on October 17, 2016, and became part of the OpenJS Foundation when that merged with the Node.js Foundation in March 2019.

In the 2020s faster tools written in Go and Rust took over new projects; Koppers himself is on the team behind Turbopack, which Next.js 16 made its default bundler in October 2025. webpack’s 2026 roadmap, from its technical steering committee, aims to keep it a “stable and well-supported choice” by folding common plugins into the core and preparing webpack 6, while asking for donations to pay its volunteer contributors.

Why it’s built this way

Code splitting from the start
Koppers wanted GWT’s ability to load parts of an app on demand. Building bundles around split points let large apps such as Instagram load only the code a page needs.
Everything is a module, through loaders
Treating CSS, images and other files as modules that loaders transform let one dependency graph cover the whole front end, instead of separate pipelines per file type.
Zero configuration with modes (webpack 4)
Every project had to write a config file, even when it needed nothing beyond an entry and an output. Defaults for those, plus a production or development mode that turns on the matching optimisations, let small projects start without one.
Move common plugins into the core (2026 roadmap)
CSS extraction, HTML generation and TypeScript each needed a separate plugin or loader. Building them in reduces dependencies and gives a volunteer team fewer packages to maintain.

Timeline

  1. 2012

    Tobias Koppers starts webpack

  2. 2014

    webpack 1.0 in February; Instagram’s use presented at OSCON

  3. 2016

    Joins the JS Foundation at its launch on October 17

  4. 2018

    webpack 4 in February: mode and optional configuration

  5. 2019

    Becomes a founding project of the OpenJS Foundation

  6. 2020

    webpack 5 on October 10: persistent caching and Module Federation

  7. 2025

    Next.js 16 switches its default bundler to Turbopack

  8. 2026

    Roadmap folds CSS, HTML and TypeScript support into the core ahead of webpack 6

Sources10 · facts checked 28 October 2026

Improve this page on GitHub