Frontend

There’s a Thing Called Webpack

Flynn Cheng

Flynn Cheng

— 6 min read
There’s a Thing Called Webpack
Photo by Annie Spratt / Unsplash

If you’ve ever built a modern JavaScript app—especially with React, Vue, or Angular—you’ve likely encountered Webpack. But what exactly is it? Why is it important? And is it still relevant in 2025?

This guide breaks down what Webpack is, how it works, and why you might still want to use it—even in a world full of newer tools like Vite and esbuild.

What Is Webpack?

Webpack is a module bundler for JavaScript applications. At its core, it takes all the files and modules in your project—JS, CSS, images, etc.—and bundles them into one or more output files (usually bundle.js) for the browser.

Webpack does 3 key things:

  1. Compiles your code from ES6/TypeScript/SCSS/etc. into browser-friendly formats.
  2. Bundles all dependencies into fewer files to optimize loading.
  3. Optimizes your assets (minifies, compresses, tree-shakes unused code).

How It Works

Webpack builds a dependency graph by starting at your entry point (like src/index.js) and walking through every import or require statement.

  1. Entry

You define an entry point:

entry: './src/index.js'
  1. Loaders

Webpack uses loaders to transform files:

  • Babel Loader: for JS/TS
  • CSS Loader & Style Loader: for stylesheets
  • File Loader: for images/fonts
  1. Plugins

Plugins do things like:

  • Minify JS (TerserPlugin)
  • Clean old build files (CleanWebpackPlugin)
  • Generate HTML (HtmlWebpackPlugin)
  1. Output

It bundles the files and outputs them to:

output: {
  filename: 'bundle.js',
  path: path.resolve(__dirname, 'dist')
}

A Sample webpack.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist'),
    clean: true,
  },
  module: {
    rules: [
      { test: /\.js$/, use: 'babel-loader', exclude: /node_modules/ },
      { test: /\.css$/, use: ['style-loader', 'css-loader'] },
      { test: /\.(png|svg|jpg|gif)$/, type: 'asset/resource' }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({ template: './src/index.html' })
  ],
  devServer: {
    static: './dist',
    hot: true,
  },
  mode: 'development', // or 'production'
};

How Webpack Handles All Kinds of Imports

At the heart of Webpack’s power is its ability to parse and understand different types of import statements, whether they’re used for JavaScript modules, CSS, images, or dynamic features like code-splitting.

Let's break down how Webpack sees all kinds of import statements and what happens under the hood when it encounters them.

Static ES Module Imports

import _ from 'lodash';
import Button from './components/Button';

These are standard ES6 imports, and Webpack processes them statically at build time. It:

  • Resolves the module path using resolve config rules (e.g., extensions, alias).
  • Traverses the dependency graph and includes the imported file in the bundle.
  • Applies configured loaders (like Babel, TypeScript, etc.) to transform the code.
These are preferred for optimal tree-shaking and static analysis.

CommonJS require

const fs = require('fs');
const config = require('./config.json');

Webpack also understands CommonJS syntax (require()), though it’s not as friendly for tree-shaking.

  • Static require() calls are bundled similarly to import.
  • Dynamic or conditional require()s may be partially analyzed but often require additional hints (require.context, externals, or dynamic imports).
Tree-shaking doesn’t work well with require() syntax. ES modules are preferred when possible.

Dynamic Imports (import())

const module = await import('./heavy-module.js');

Dynamic import() returns a Promise and tells Webpack to create a separate chunk for that module. This is useful for:

  • Code splitting
  • Lazy loading
  • Improving initial load performance

Webpack automatically handles splitting and loading these modules asynchronously. You can configure how chunks are named using webpackChunkName comments:

import(/* webpackChunkName: "heavy" */ './heavy-module.js');

CSS and Other Asset Imports

import './styles/main.scss';
import logo from './assets/logo.png';

Webpack can treat non-JS files as modules using loaders:

  • style-loader + css-loader for CSS
  • sass-loader for SCSS
  • file-loader or asset modules (Webpack 5) for images, fonts, etc.

When Webpack sees these imports, it:

  • Runs them through the appropriate loader pipeline
  • Inlines or extracts the result depending on configuration (e.g., MiniCssExtractPlugin)
  • Optionally optimizes assets (e.g., via image-webpack-loader)

Webpack 5 introduced Asset Modules as a cleaner replacement for file-loader and url-loader.

require.context for Dynamic Contextual Imports

const context = require.context('./components', true, /\.js$/);
context.keys().forEach(context);

Webpack allows you to dynamically import multiple files that match a pattern with require.context. It:

  • Creates a context module which contains references to all matching files.
  • Useful for scenarios like auto-registering components.

This is not standard JS, but a Webpack-specific feature.

Importing JSON, WASM, or Other Formats

import data from './data.json';
import wasm from './module.wasm';

Webpack supports importing .json out of the box, and .wasm with proper configuration. You can also configure custom loaders for XML, CSV, Markdown, and more.

What the Final Bundle Looks Like

Webpack wraps all modules (files like .js, .css, .jsx, .png) into an object and passes it into an Immediately Invoked Function Expression (IIFE) to simulate a module system in the browser.

The Whole Function

(function(modules) {
  // Webpack runtime
  function __webpack_require__(id) { ... }

  // Start from the entry module
  return __webpack_require__('./src/index.js');
})(/* modules */)
  • modules is an object containing all your files.
  • __webpack_require__ is a custom function that mimics require() – it loads a module based on its path.
  • Webpack starts with the entry file (e.g., index.js), just like you define in webpack.config.js.

It takes all of those inputs — code, styles, assets — and bundles them into a JavaScript file like this (simplified):

(function(modules) {
  // Webpack runtime
  function __webpack_require__(id) { ... }

  // Start from the entry module
  return __webpack_require__('./src/index.js');
})({
  './src/index.js': function(module, exports, __webpack_require__) {
    const Button = __webpack_require__('./Button.jsx');
    __webpack_require__('./styles.css');
  },

  './Button.jsx': function(...) {
    // transpiled React component
  },

  './styles.css': function(...) {
    // style-loader injects <style> into DOM
  },

  './logo.png': function(...) {
    module.exports = '/dist/7c8b3e.png';
  }
});

This is how Webpack bundles your project internally after analyzing all your files (.js, .jsx, .css, .png, etc.).

Webpack takes all your modules and wraps them inside an object, where each key is a file path, and each value is a function that defines that module.

Individual Modules

Browsers don’t support require() or import natively for local files unless you use a bundler or module loader. So Webpack recreates Node-like module resolution in the browser using __webpack_require__. It’s Webpack’s way of simulating a module system in the browser.

'./src/index.js'

function(module, exports, __webpack_require__) {
  const Button = __webpack_require__('./Button.jsx');
  __webpack_require__('./styles.css');
}
  • Webpack bundles your index.js file.
  • It requires Button.jsx and styles.css using its custom system.

'./Button.jsx'

function(...) {
  // transpiled React component
}
  • Webpack transpiles this with Babel, turns JSX into regular JS.
  • It might look like:
module.exports = function Button() { return React.createElement("button", null, "Click"); }

'./styles.css'

function(...) {
  // style-loader injects <style> into DOM
}

CSS doesn’t export variables — instead, Webpack uses style-loader or MiniCssExtractPlugin to inject this CSS into a <style> tag in your HTML or DOM.

'./logo.png'

function(...) {
  module.exports = '/dist/7c8b3e.png';
}

Webpack copies the image to the dist/ folder and exports the path as a string.

If you wrote:

import logo from './logo.png';

Then logo becomes "/dist/7c8b3e.png".

Source Maps

Source maps are maps between your original code and the transformed bundle, so when an error occurs or you debug in the browser, you see the real source file and line number, not the minified or bundled code.

// You wrote this in src/App.jsx:10
throw new Error('Something went wrong');

Without source maps:

  • Browser says the error is in bundle.js:1:5000

With source maps:

  • Browser maps that back to App.jsx

How to Enable in Webpack:

module.exports = {
  devtool: 'source-map', // or 'cheap-module-source-map', etc.
};

Conclusion

Webpack is incredibly flexible when it comes to interpreting various kinds of imports. Whether you’re pulling in a JavaScript module, dynamically loading a component, importing SCSS styles, or embedding an image, Webpack uses its loader and plugin system to make sense of it and include it properly in your final bundle.

To get the most out of Webpack’s capabilities:

  • Prefer static import when possible
  • Use import() for lazy loading
  • Leverage loaders for asset handling
  • Avoid magic in dynamic require() calls

While newer tools like Vite and esbuild offer faster builds and a smoother development experience, Webpack remains a powerful and relevant tool in 2025, especially for large-scale applications that demand fine-grained control over the build process.

Its flexibility, ecosystem of loaders/plugins, and ability to handle complex module graphs make it indispensable in many enterprise-level workflows. Understanding how Webpack works under the hood not only helps you debug tricky build issues but also deepens your grasp of how JavaScript gets bundled, optimized, and shipped to the browser.

Even if you’re starting with Vite or esbuild today, knowing Webpack is still a valuable skill—and often necessary when you’re working on legacy codebases or contributing to widely used open-source projects.

Read more