webpack-dev-server: local install, port 8080, and three migration guides

Install it locally, because a local copy always wins

Three package managers, one rule. The install step is a dev dependency:

npm install webpack-dev-server --save-dev

yarn add -D webpack-dev-server

pnpm add -D webpack-dev-server

The note under them is the part worth remembering: while you can install and run webpack-dev-server globally, the project recommends installing it locally, and webpack-dev-server will always use a local installation over a global one.

So a stale global copy is not what you accidentally run; the failure mode is the opposite, where a project with no local dependency silently picks one up from your PATH and behaves like a different version. Pinning it as a dev dependency is what makes the version reproducible.

The server itself is built on webpack-dev-middleware, which the README names as the piece under the hood providing fast in-memory access to the webpack assets. Nothing is written to disk between a rebuild and the browser.

npx webpack serve, or an npm script that already knows the path

There are two recommended ways to start it, and the second saves you a path.

With the CLI, in the directory where your `webpack.config.js` lives:

npx webpack serve

The options it accepts are printed by that command, beginning with the usage line `webpack serve|server|s [entries...] [options]`, then `-c` or `--config` for a configuration file path, `--config-name` to pick one of several named configurations, `-m` or `--merge` to merge two or more configurations using webpack-merge, `--disable-interpret` to turn off interpret when loading the config file, and `--env` to pass an environment through.

With an npm script, the package.json entry is:

{
  "scripts": {
    "serve": "webpack serve"
  }
}

and then `npm run serve` in the terminal. The stated benefit is that npm refers to the binary in `node_modules` for you, so the script works without anyone knowing where it was installed.

It listens on localhost 8080 and live reloads by default

The result section is three sentences and settles the questions most people ask first.

Either method will start a server instance and begin listening for connections from `localhost` on port `8080`.

And webpack-dev-server is configured by default to support live reload of files as you edit your assets while the server is running.

So the defaults are deliberately unopinionated and narrow: one host, one port, and reload on change. Everything else, from proxies to HTTPS to history API fallback, lives in the `devServer` configuration object, and the README sends you to the configuration documentation for those.

The examples directory in the repository is the practical version of that documentation, and it includes `host-and-port/`, `proxy/`, `https` is absent but `headers/`, `compression/`, `history-api-fallback/`, `hmr/`, `bonjour/`, `open-target/`, `setup-middlewares/`, `multi-compiler/` and `client/` are all there as runnable projects rather than prose.

TypeScript needs a hand before devServer type checks

If your webpack config is typed, the `devServer` property does not type check out of the box, and the error people see is `'devServer' does not exist in type 'Configuration'`.

The README gives two fixes. The first is a triple-slash reference to the declaration file shipped in the package:

/// <reference path="node_modules/webpack-dev-server/types/lib/Server.d.ts"/>
import { type Configuration } from "webpack";

// Your logic

The second is to import the dev server configuration type under its own name and assemble the config:

import { type Configuration } from "webpack";
import { type Configuration as DevServerConfiguration } from "webpack-dev-server";

const devServer: DevServerConfiguration = {};
const config: Configuration = { devServer };

// module.exports
export default config;

The path in the first snippet is the tell: the types live at `types/lib/Server.d.ts`, which is also what the package's exports map points at for the types condition. If your resolver is not looking there, the reference does nothing and the error stays.

Version 6 is ESM-first, with a require path kept for compatibility

The package manifest for 6.1.0 is worth reading once, because the dual build is deliberate.

`type` is `module`. The exports map for the root entry has four conditions: `types` pointing at `./types/lib/Server.d.ts`, `import` at `./lib/Server.js`, `require` at `./dist/Server.js`, and `default` at `./lib/Server.js`. Alongside it, `main` is `./dist/Server.js` and `module` is `./lib/Server.js`, so a bundler that reads `module` gets the ESM source while `require` still resolves to the compiled CommonJS build.

Two subpaths are exported as well, `./client/*` and `./lib/servers/BaseServer.js`, plus `./package.json`. The published `files` list is bin, lib, dist, client and types, and the binary itself is `bin/webpack-dev-server.js`.

If you are upgrading from an older major and something resolves to the wrong build, this map is the place to look, and the migration documents are named in the repository root alongside a DOCUMENTATION-v4.md.

Four migration documents, and the major shipped a day before the last 5.x patch

The repository root contains `migration-v4.md`, `migration-v5.md` and `migration-v6.md`, plus `DOCUMENTATION-v4.md`. A project that keeps one document per major is telling you what its upgrade path costs.

The release dates show the 6.x move: v6.0.0 on 2026-07-03, then v6.1.0 and v5.2.7 both on 2026-10-18, so the 5.x line still gets patches alongside 6.x. The last push to main was on 2026-10-30.

The rest of the root explains how the project is run: `.changeset/` and `CHANGELOG.md` for release notes, `.husky/` with lint-staged for commit hooks, a `.versionrc` for version management, babel for transpiling the client, `tsconfig.json` with a separate `tsconfig.client.json`, and a spelling check through cspell.

Practically: read the migration document for the version you are jumping to before you change your config, because the export map, the type paths and the option names are exactly what moves.

Two major versions of browser support, and a deliberate support policy

The browser support statement is short and unapologetic. webpack-dev-server transpiles the client, the browser side scripts, to an ES5 state, but the project only officially supports the last two versions of major browsers, with the stated reason that they do not have the resources to support every whacky browser out there. Bugs in obscure or old browsers are welcome as pull requests.

So the ES5 transpilation is not a compatibility promise. It reduces syntax problems in your own client code and does not extend the project's support window.

The support policy is just as defined. Issues in the repository are for bugs, features and needed modifications to the code, and general support, how-to and why-isn't-this-working questions are asked to go elsewhere: the configuration documentation first, then the webpack discussions, then StackOverflow, with the reminder that questions are much easier to answer when they include your `webpack.config.js` and the relevant files. The issue template is not optional, and it is meant to be filled in completely.

One more line of credit: the project is heavily inspired by peerigon's nof5, which is where the server design came from.

Editorial conclusion

webpack-dev-server suits a webpack project that wants a development server with live reload and an in-memory asset store, and whose team is ready to read one configuration reference rather than a tutorial. It does not suit a project that wants a production server, because the README says it should be used for development only, and it does not suit you if you need support beyond the last two major browser versions. Verify three things before you upgrade: which migration document applies to you, since the repository ships migration-v4.md, migration-v5.md and migration-v6.md, whether your TypeScript config still types the `devServer` property after the upgrade, and that the local install won the resolution, because webpack-dev-server always uses a local installation over a global one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. webpack/webpack-dev-server on GitHub