How to Fix the Error Overlay Not Showing in webpack-dev-server 4 (Runtime Errors Invisible)

Threat/Impact Level: MEDIUM | Downtime Risk: HIGH (silent failures during dev) | Time to Fix: 5 mins

TL;DR

• What broke: webpack-dev-server v4 restructured the devServer config API — the overlay option moved and its boolean shorthand was deprecated, so runtime errors and compile errors no longer surface in the browser overlay.
• How to fix it: Replace the legacy overlay: true boolean with the v4 object syntax: overlay: { errors: true, warnings: false } inside devServer.
• Fast path: Use our Client-Side Sandbox below to auto-refactor this — paste your webpack.config.js and get a corrected diff without sending your config to any external server.

The Incident (What Does the Error Mean?)

You upgrade to [email protected] and runtime errors in your React/Vue/vanilla app stop appearing as the red overlay in the browser. The terminal shows compile output, but the browser renders a blank white screen or a stale UI with zero feedback. No overlay. No console error from WDS itself.

Raw symptom in terminal:

[webpack-dev-server] Server started: Hot Module Replacement enabled, Live Reloading enabled, Progress disabled, Overlay disabled.

Or silently, nothing — the overlay config key is accepted but ignored because the shape changed.

The immediate consequence: developers lose the fast-feedback loop. Errors get missed, bad code ships to staging, and junior devs spend 20 minutes wondering why the app is blank.

The Attack Vector / Blast Radius

This is a developer experience and release integrity failure, not a CVE — but the blast radius is real:

• Silent runtime failures mean broken components reach staging/UAT undetected.
• Teams running webpack-dev-server behind a Docker devcontainer or WSL2 often can't easily inspect the browser console, making the overlay the only practical error surface.
• If your CI pipeline runs webpack-dev-server for integration/E2E tests (Cypress, Playwright), a missing overlay won't fail the test runner — errors are swallowed, and green pipelines ship broken builds.
• The v3→v4 migration guide buried this change. Most projects hit it silently after a npm audit fix or a lockfile refresh bumps the minor version.

How to Fix It (The Solution)

Basic Fix

The overlay key in devServer no longer accepts a raw boolean in v4. It requires an object.

// webpack.config.js
 module.exports = {
   devServer: {
     port: 3000,
     hot: true,
-    overlay: true,
+    client: {
+      overlay: {
+        errors: true,
+        warnings: false,
+        runtimeErrors: true,
+      },
+    },
   },
 };

Critical path: The overlay option moved inside devServer.client in webpack-dev-server 4. Placing it directly under devServer is silently ignored.

Enterprise Best Practice

For monorepos or teams managing multiple apps, centralize the devServer client config and add runtimeErrors filtering to suppress known noisy third-party errors (e.g., browser extension injections):

// webpack.config.js
 module.exports = {
   devServer: {
     port: process.env.DEV_PORT || 3000,
     hot: true,
-    overlay: {
-      errors: true,
-      warnings: true,
-    },
+    client: {
+      overlay: {
+        errors: true,
+        warnings: false,
+        runtimeErrors: (error) => {
+          // Suppress extension-injected errors, surface all app errors
+          if (error?.message?.includes('ResizeObserver loop')) return false;
+          return true;
+        },
+      },
+      logging: 'error',
+      reconnect: 5,
+    },
   },
 };

This pattern:

• Reduces noise from browser extension errors that pollute the overlay
• Surfaces only actionable errors to developers
• Centralizes devServer behavior for webpack-merge base configs

💡 Tired of pasting proprietary configs into ChatGPT? Generic AI tools log your company's ARNs, DB strings, and private keys. StackEngine is a zero-backend, pure Client-Side WASM utility. Drop your failing config into the sandbox above. We redact your secrets locally in the browser and auto-generate the refactored code using your own API key.

Prevention in CI/CD

1. Pin your webpack-dev-server minor version in package.json:

"webpack-dev-server": "~4.15.0"

Avoid ^4.x.x — minor bumps in WDS have historically introduced breaking config changes.

2. Add a config validation step with webpack-cli:

npx webpack configtest --config webpack.config.js

Run this in your CI pipeline's lint stage. It catches schema violations before a developer wastes a morning debugging a blank browser.

3. Use eslint-plugin-webpack or a custom config schema test:

// scripts/validate-webpack-dev-server.js
const config = require('../webpack.config.js');
const assert = require('assert');
assert(
  typeof config.devServer?.client?.overlay === 'object',
  'FATAL: devServer.client.overlay must be an object in WDS4. Boolean is silently ignored.'
);
console.log('webpack devServer config: OK');

Wire this into your prestart npm script so it fails loudly before webpack serve ever runs.

4. Dependabot / Renovate config — require manual review for WDS major/minor bumps:

# .github/renovate.json
{
  "packageRules": [
    {
      "matchPackageNames": ["webpack-dev-server"],
      "matchUpdateTypes": ["minor", "major"],
      "requireApproval": true,
      "labels": ["needs-webpack-audit"]
    }
  ]
}