What's the difference between development and production mode?

Webpack's `mode` option applies a different built-in set of optimizations for each: "development" favors fast rebuilds and readable output (no minification), while "production" enables minification, tree-shaking, and other size optimizations at the cost of slower builds. Always ship the production mode build, never the development one.

Do I need both babel-loader and css-loader?

Only if your project needs them: babel-loader transpiles modern JS/JSX/TS through Babel so older environments and JSX/TS syntax work, and css-loader (paired with style-loader) lets webpack understand `import "./styles.css"` statements in JS. Skip either toggle if your project doesn't have that kind of source file.

Why is clean: true set on output?

It removes the contents of the output directory before each build, replacing the older clean-webpack-plugin's job as a built-in webpack 5 output option, so stale files from a previous build (with a different content hash) don't accumulate in dist.

What does devServer actually run?

It configures webpack-dev-server, a local development server with in-memory bundling and (by default) hot module replacement, letting you run `webpack serve` and see changes without a manual rebuild-and-refresh cycle.

Webpack Config Generator - webpack.config.js Builder

Overview

Introduction

A first webpack.config.js usually needs the same core pieces, entry/output paths, a mode setting, a loader rule or two, and a dev server, but assembling the correct module.rules shape and matching plugin imports from webpack's documentation across several pages takes a while.

This tool generates a working webpack.config.js with all of that from a simple form, as real CommonJS ready to run with `webpack` or `webpack serve`.

What Is Webpack Config Generator?

A webpack.config.js generator covering entry/output, the development/production mode toggle, babel-loader and css-loader module rules, a devServer block, and three common plugins (HtmlWebpackPlugin, MiniCssExtractPlugin, CleanWebpackPlugin).

The output uses webpack 5's built-in `output.clean: true` for output-directory cleanup and only includes the loader rules, plugins, and devServer block you actually enabled.

How Webpack Config Generator Works

Enabling babel-loader or css-loader appends the matching rule object (with the correct `test` regex and `use` chain) to `module.rules`; enabling a plugin adds both its `require()` import and its constructor call to the plugins array.

The devServer block, including `port`, is only emitted when you provide a port number, and everything is serialized as real JavaScript object literals rather than JSON, matching how webpack.config.js is actually written and loaded by Node.

When To Use Webpack Config Generator

Use it when setting up webpack from scratch for a project that isn't using a higher-level tool like Vite or Next.js, and you want correct entry/output/rules/devServer wiring without assembling it from documentation.

It's also useful for quickly producing a comparison config when evaluating whether to migrate a webpack-based project to a different bundler.

Often used alongside Babel Config Generator, package.json Generator and Vite Config Generator.

Features

Advantages

Produces the correct `test`/`use` shape for babel-loader and css-loader rules, a common source of typos when writing webpack config by hand.
Only includes plugins, loader rules, and the devServer block you actually enabled, avoiding a config full of no-op empty sections.
Uses webpack 5's built-in `output.clean` option instead of requiring the separate, now largely redundant clean-webpack-plugin package by default.

Limitations

Covers a common starter set (babel-loader, css-loader, HtmlWebpackPlugin, MiniCssExtractPlugin, CleanWebpackPlugin); advanced setups (code splitting, module federation, custom loaders) need manual configuration on top.
Doesn't install the referenced loader/plugin packages; each enabled option still needs `npm install --save-dev` for the matching package.

Examples

Production build with babel-loader and HtmlWebpackPlugin

Input

entry: ./src/index.js, mode: production, babel-loader: true, plugins: [HtmlWebpackPlugin]

Output

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

module.exports = {
  mode: "production",
  entry: "./src/index.js",
  output: {
    filename: "bundle.[contenthash].js",
    path: path.resolve(__dirname, "dist"),
    clean: true,
  },
  module: {
    rules: [
      {
        test: /\.[jt]sx?$/,
        exclude: /node_modules/,
        use: "babel-loader",
      },
    ],
  },
  plugins: [
    new HtmlWebpackPlugin({ template: "./public/index.html" }),
  ],
};

Best Practices & Notes

Best Practices

Always set mode explicitly ("development" or "production") rather than relying on webpack's fallback, since an unset mode produces neither set of optimizations and warns on every build.
Use `[contenthash]` in the output filename (as this generator does by default) so long-term browser caching works correctly, only files that actually changed content get a new hash and cache-bust.
Add MiniCssExtractPlugin for production builds instead of style-loader's runtime style injection, so CSS ships as a separate cacheable file rather than being injected via JavaScript.

Developer Notes

The babel-loader rule's `test` regex (`/\.[jt]sx?$/`) matches .js, .jsx, .ts, and .tsx in one pattern, and `exclude: /node_modules/` keeps webpack from re-transpiling already-published dependency code, which is both usually unnecessary and can be very slow on a large node_modules tree. `output.clean: true` was added in webpack 5 as a built-in replacement for clean-webpack-plugin's core use case; this generator still offers clean-webpack-plugin as an optional legacy plugin choice for projects intentionally targeting older webpack conventions or needing its extra options.

Webpack Config Generator Use Cases

Bootstrapping webpack.config.js for a new project not using a higher-level framework or Vite
Adding a devServer block with hot reloading for local development
Producing a starting-point config to compare against Vite or Rollup when evaluating a bundler migration

Common Mistakes

Forgetting to set `mode`, causing webpack to warn and fall back to an unoptimized default instead of the intended development or production behavior.
Using style-loader in a production build instead of MiniCssExtractPlugin, shipping CSS injected via JavaScript instead of as a separate cacheable stylesheet.

Tips

Use the Babel Config Generator alongside this if babel-loader is enabled, so babel.config.js actually exists for babel-loader to read.

Webpack Config Generator