diff --git a/src/assets/blog/webpack-5-108.png b/src/assets/blog/webpack-5-108.png
new file mode 100644
index 000000000000..57b5e556838f
Binary files /dev/null and b/src/assets/blog/webpack-5-108.png differ
diff --git a/src/content/blog/2026-06-25-webpack-5-108.mdx b/src/content/blog/2026-06-25-webpack-5-108.mdx
new file mode 100644
index 000000000000..47306006c8b6
--- /dev/null
+++ b/src/content/blog/2026-06-25-webpack-5-108.mdx
@@ -0,0 +1,402 @@
+---
+title: Webpack 5.108
+sort: 20260618
+contributors:
+  - bjohansebas
+---
+
+import banner from "../../assets/blog/webpack-5-108.png";
+
+<img src={banner} alt="webpack 5.108 release" />
+
+Webpack 5.108 is out, and it pushes two big stories forward. The headline is a brand-new `universal` target: a single preset that compiles one bundle which adapts at runtime to the browser, web workers, Node.js, Electron, and NW.js, replacing the hand-written `target: ["web", "node"]` setups people have been maintaining for years. The release also continues the native HTML work that started in 5.107: a `.html` file can now be used directly as an `entry`, webpack can emit an HTML file for plain JavaScript entries, and HTML modules now support Hot Module Replacement.
+
+Around those headlines, this release lands a substantial round of tree-shaking improvements (a new `optimization.inlineExports`, cross-module purity, and CommonJS re-export analysis), modernizes the code webpack generates for capable targets, and adds a typed `defineConfig` helper.
+
+Both the HTML and `universal` features are experimental and live behind opt-in flags, but the direction stays the same as 5.107: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML, CSS, and TypeScript.
+
+Explore what's new:
+
+- [**The `universal` Target**](#the-universal-target)
+- [**Bun and Deno Targets**](#bun-and-deno-targets)
+- [**HTML Modules: Entry Points and HMR**](#html-modules-entry-points-and-hmr)
+  - [HTML as an Entry Point](#html-as-an-entry-point)
+  - [HTML Output for JavaScript Entries](#html-output-for-javascript-entries)
+  - [Hot Module Replacement](#hot-module-replacement)
+  - [Customizing the HTML Parser](#customizing-the-html-parser)
+- [**CSS Improvements**](#css-improvements)
+  - [`url()` Inside HTML `style` Attributes](#url-inside-html-style-attributes)
+  - [CSS in Node for Universal Builds](#css-in-node-for-universal-builds)
+- [**Tree Shaking**](#tree-shaking)
+  - [`optimization.inlineExports`](#optimizationinlineexports)
+  - [Cross-Module Dead-Branch Skipping](#cross-module-dead-branch-skipping)
+  - [Cross-Module Purity](#cross-module-purity)
+  - [CommonJS Re-exports via `Object.defineProperty`](#commonjs-re-exports-via-objectdefineproperty)
+- [**Automatic ES Module Detection**](#automatic-es-module-detection)
+- [**Output and Runtime**](#output-and-runtime)
+  - [Modern Syntax in Generated Code](#modern-syntax-in-generated-code)
+  - [`output.strictModuleResolution`](#outputstrictmoduleresolution)
+  - [`[uniqueName]` Template Placeholder](#uniquename-template-placeholder)
+  - [Worker Chunk Filenames](#worker-chunk-filenames)
+- [**Typed Configuration with `defineConfig`**](#typed-configuration-with-defineconfig)
+- [**Bug Fixes**](#bug-fixes)
+
+## The `universal` Target
+
+Building code that runs in more than one environment used to mean hand-writing `target: ["web", "node"]` and then dealing with the rough edges yourself: choosing a chunk format that loads everywhere, wiring up a global object, and guarding every platform-specific API by hand. Webpack 5.108 turns that into a single preset.
+
+```js
+// webpack.config.js
+module.exports = {
+  target: "universal",
+};
+```
+
+[`target: "universal"`](/configuration/target/#universal) combines the `web`, `web worker`, `node`, `electron`, and `nwjs` platforms into one target and leaves each platform flag _neutral_ instead of locking the bundle to a single environment. Rather than compiling separate web and node bundles, you ship one bundle that figures out its surroundings at runtime and uses whatever the current platform provides.
+
+A bundle that has to load equally well in a browser and in Node needs a portable module format, so universal builds always output ECMAScript modules: [`experiments.outputModule`](/configuration/experiments/#experimentsoutputmodule) defaults to `true`, synchronous `require` is turned off, and Node's built-in modules stay available (resolved at runtime through ESM). [`output.globalObject`](/configuration/output/#outputglobalobject) also defaults to `globalThis` so runtime code has one global to reach for on every platform.
+
+To make a single bundle behave correctly everywhere, several pieces were made platform-aware and now branch on feature detection at runtime instead of being fixed at build time:
+
+- **Workers**: `new Worker(new URL(...))` resolves the `Worker` constructor from `worker_threads` in Node and from the global `Worker` on the web, so the same worker entry runs in both.
+- **Externals**: `commonjs` and `node-commonjs` externals work from the ESM output (loaded defensively via `createRequire` obtained from `process.getBuiltinModule`, guarded so they never break in the browser), and `global` externals resolve against `globalThis`. Electron externals use `module-import` when the target supports ESM.
+- **CSS for SSR**: on the server, where there is no DOM to inject into, styles are collected into a registry an SSR host can read (see [CSS in Node for Universal Builds](#css-in-node-for-universal-builds)).
+
+Plugins and loaders can detect a universal build at compile time through `compiler.platform.universal`, which is also `true` for the equivalent `target: ["web", "node"]`.
+
+For a complete, runnable setup, see the [`universal` example](https://github.com/webpack/webpack/tree/main/examples/universal) in the webpack repository.
+
+## Bun and Deno Targets
+
+Alongside `universal`, webpack 5.108 adds dedicated presets for two newer JavaScript runtimes. Each one configures ESM output and marks the runtime's own built-in modules as externals (so they're left for the runtime to provide instead of being bundled), which previously you had to set up by hand.
+
+[`target: "bun"`](/configuration/target/#string) builds for Bun, externalizing Bun's own `bun:*` modules and the Node.js built-ins it provides instead of bundling them.
+
+```js
+// webpack.config.js
+module.exports = {
+  target: "bun",
+};
+```
+
+[`target: "deno"`](/configuration/target/#string) builds for Deno. It resolves Node.js built-ins through the `node:` specifier that Deno requires, and keeps Deno's own import protocols (`npm:`, `jsr:`, `node:`, and `http(s)://` URLs) external so the runtime loads them. Like webpack's other version-aware targets, it accepts a version such as `deno2` or `deno1.40`.
+
+```js
+// webpack.config.js
+module.exports = {
+  target: "deno", // also "deno2", "deno1.40", ...
+};
+```
+
+## HTML Modules: Entry Points and HMR
+
+W> **This feature is experimental and partial.** Webpack 5.107 implemented the `html-loader` side of the story: importing an HTML file from JavaScript runs its tag references through the webpack pipeline. Webpack 5.108 adds the ability to use a `.html` file as an `entry`. Full parity with `html-webpack-plugin` is still in progress; the overall effort is tracked in issue [#536](https://github.com/webpack/webpack/issues/536).
+
+### HTML as an Entry Point
+
+With [`experiments.html`](/configuration/experiments/#experimentshtml) enabled, you can now point `entry` directly at an HTML file. Its `<script src>` and `<link rel="stylesheet">` references go through webpack's pipelines, and the emitted HTML is rewritten to point at the generated JS and CSS chunks.
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: {
+    html: true,
+    css: true,
+  },
+  entry: {
+    page: "./page.html",
+  },
+};
+```
+
+To make this feel like Vite or Parcel, webpack 5.108 also adds `.html` (and `.css`, when [`experiments.css`](/configuration/experiments/#experimentscss) is enabled) to the default `resolve.extensions`, ahead of the JavaScript extensions. With the HTML experiment on, the default `./src` entry therefore resolves `./src/index.html` over `./src/index.js`:
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: { html: true },
+  entry: "./src", // resolves to ./src/index.html
+};
+```
+
+These extensions are only added when the matching experiment is enabled, so default builds are unchanged.
+
+### HTML Output for JavaScript Entries
+
+The previous section starts from an HTML file. [`output.html`](/configuration/output/#outputhtml) covers the opposite case: when your entries are plain JavaScript, webpack emits an HTML file for every non-HTML entrypoint and injects that entrypoint's initial JS (deferred, or `type="module"` for ESM output) and CSS chunks for you. This is the part of `html-webpack-plugin` that scaffolds a document around your bundles, now built in.
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: { html: true },
+  entry: {
+    main: "./src/main.js",
+  },
+  output: {
+    html: true,
+  },
+};
+```
+
+Shared chunks pulled in through [`dependOn`](/configuration/entry-context/#dependencies) are handled correctly: a dependant entry's page loads its `dependOn` targets' chunks first (transitively, with diamond graphs deduplicated) instead of inlining the shared modules into the dependant's own chunk. Under the hood each entrypoint is wrapped in a synthetic HTML module that flows through the same pipeline as a real `entry: "./index.html"`, so chunk injection, `publicPath`, and the `template` option behave the same way. For per-entry control, the entry descriptor also accepts an `html` field.
+
+### Hot Module Replacement
+
+HTML modules now support [Hot Module Replacement](/concepts/hot-module-replacement/). There's nothing to configure: it activates automatically when HMR is enabled, for example via [`devServer.hot`](/configuration/dev-server/#devserverhot).
+
+For a page extracted to a real `.html` file, each hot update patches `document.body.innerHTML` and `document.title` in place instead of triggering a full reload. Changes to `<head>` beyond the `<title>` (a new `<meta>`, a swapped `<link rel="icon">`, and so on) can't be safely DOM-patched, so the shim falls back to a full page reload.
+
+### Customizing the HTML Parser
+
+Two new options under [`module.parser.html`](/configuration/module/#moduleparserhtml) give you control over how HTML modules are processed.
+
+[`sources`](/configuration/module/#moduleparserhtmlsources) controls which URL-like attributes become webpack dependencies. Set it to `false` to disable extraction entirely, or pass an array to customize which `tag`/`attribute` pairs are treated as URLs. Use the literal string `"..."` to keep the built-in defaults:
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: { html: true },
+  module: {
+    parser: {
+      html: {
+        sources: [
+          "...", // keep the built-in defaults
+          { tag: "img", attribute: "data-src", type: "src" },
+          { attribute: "data-href", type: "src" }, // any tag
+        ],
+      },
+    },
+  },
+};
+```
+
+The built-in defaults also got broader in 5.108: the parser now extracts more URLs out of the box (including SVG references and various legacy or obsolete attributes), decodes HTML character references, and supports a new `css-url` source type that pulls `url()` references out of CSS-valued attributes.
+
+[`template`](/configuration/module/#moduleparserhtmltemplate) transforms the raw HTML source **before** the parser extracts dependencies, so URLs emitted by a templating language (Handlebars, EJS, Eta, …) are still discovered and bundled. It runs synchronously and must return the HTML string to parse:
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: { html: true },
+  module: {
+    parser: {
+      html: {
+        template: (source, { resource, addDependency }) => {
+          addDependency(resource);
+          return source
+            .replaceAll("{{title}}", "Hello world")
+            .replaceAll("{{image}}", "./image.png");
+        },
+      },
+    },
+  },
+};
+```
+
+## CSS Improvements
+
+### `url()` Inside HTML `style` Attributes
+
+Webpack can now route an HTML inline `style="..."` attribute through the CSS pipeline, resolving `url()` and `image-set()` inside it relative to the HTML file. This is powered by a new [`module.parser.css.as`](/configuration/module/#moduleparsercssas) option that picks what to parse: `"stylesheet"` (the default) or `"block-contents"` (a declaration list, like the inside of a `style` attribute).
+
+For the common HTML case you don't need to set it manually. Just enable both experiments and `url()` inside `style` attributes resolves automatically:
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: { html: true, css: true },
+};
+```
+
+### CSS in Node for Universal Builds
+
+For the new [`universal` target](#the-universal-target), CSS now runs in Node without crashing and exposes styles for server-side rendering. Styles from `style` injection and `link`-loaded chunks are collected into a registry an SSR host can read at `globalThis["__webpack_css__" + output.uniqueName]`. Single-platform (web-only or node-only) builds emit no extra runtime, so this is scoped entirely to universal output.
+
+## Tree Shaking
+
+### `optimization.inlineExports`
+
+A new [`optimization.inlineExports`](/configuration/optimization/#optimizationinlineexports) option (on by default in `production`) inlines ESM exports that bind to small primitive constants (a `null`, `undefined`, `boolean`, `number`, or `string` of at most 6 bytes) at every import site, replacing the imported binding with the literal value.
+
+```js
+// flags.js
+export const DEBUG = false;
+```
+
+```js
+// app.js
+import { DEBUG } from "./flags.js";
+
+if (DEBUG) doSomething();
+```
+
+Every reference to `DEBUG` is replaced with `false`. Once no import references it anymore, the export is left unused and dead-code elimination drops it; if `flags.js` has no side effects, the whole module is removed too, and the consuming code can collapse the now-constant branch.
+
+### Cross-Module Dead-Branch Skipping
+
+Building on inline exports, webpack can now skip dependencies that live only in a provably-dead branch gated by an inlined imported constant. When the guarding condition can be evaluated at build time, the import specifiers, `require()` calls, and dynamic `import()` calls in the dead branch are skipped, so the unreachable modules are never bundled.
+
+{/* eslint-disable */}
+
+```js
+// app.js
+import { devOnly } from "./dev-tools";
+import { isDEV } from "./env"; // export const isDEV = false
+import { prodOnly } from "./prod-tools";
+
+export const tools = isDEV ? devOnly : prodOnly;
+```
+
+{/* eslint-enable */}
+
+Because `isDEV` inlines to `false`, the `devOnly` branch is dead and `./dev-tools` is never bundled. Supported guard forms include ternaries, `if` statements, and the `&&`, `||`, `??`, and `!` operators, including nested combinations.
+
+### Cross-Module Purity
+
+In 5.107, the [`#__NO_SIDE_EFFECTS__`](/guides/tree-shaking/#mark-a-function-declaration-as-side-effect-free) annotation only took effect within the module where it was declared. Webpack 5.108 propagates it across module boundaries, so an unused call in an importing module is tree-shaken too.
+
+{/* eslint-disable */}
+
+```js
+// pure.js
+/*#__NO_SIDE_EFFECTS__*/
+export function createThing(x) {
+  return { x };
+}
+```
+
+{/* eslint-enable */}
+
+```js
+// app.js
+import { createThing } from "./pure";
+
+const unused = createThing(1); // dropped: result is never used
+```
+
+When you can't edit the source — for example, a function coming from a dependency — the new [`module.parser.javascript.pureFunctions`](/configuration/module/#moduleparserjavascriptpurefunctions) option marks names as side-effect-free from your config instead:
+
+```js
+// webpack.config.js
+module.exports = {
+  module: {
+    rules: [
+      {
+        test: /pure-source\.js$/,
+        parser: {
+          pureFunctions: ["createSelector", "styled"],
+        },
+      },
+    ],
+  },
+};
+```
+
+### CommonJS Re-exports via `Object.defineProperty`
+
+Webpack already analyzes CommonJS re-exports such as `exports.foo = require("./foo")` for tree shaking. Webpack 5.108 extends that analysis to re-exports defined with `Object.defineProperty` descriptors, including the lazy getter form used by barrel files:
+
+```js
+// barrel.js
+Object.defineProperty(exports, "foo", {
+  enumerable: true,
+  get: () => require("./foo"),
+});
+```
+
+These re-exports are now treated as structured re-exports, so they participate in exports analysis and tree shaking. Lazy getters keep their deferred semantics in the generated code, and a `{ get, set }` descriptor keeps its setter.
+
+## Automatic ES Module Detection
+
+Webpack now treats a top-level `await` or a reference to `import.meta` as a marker that a `.js` file is an ES module, matching the syntax detection Node.js uses. A module that uses either feature is recognized as ESM even without an `.mjs` extension, a `"type": "module"` in `package.json`, or an explicit [`module.rules` type](/configuration/module/#ruletype):
+
+```js
+// config.js: no `import`/`export`, yet treated as an ES module
+// (top-level `await` and `import.meta` only parse inside a module)
+const res = await fetch(new URL("./config.json", import.meta.url));
+
+globalThis.appConfig = await res.json();
+```
+
+This makes mixed CommonJS/ESM codebases work with less configuration, since these unambiguous ESM-only syntax features no longer need to be paired with a manual `type` declaration.
+
+## Output and Runtime
+
+### Modern Syntax in Generated Code
+
+Webpack tailors the syntax of its generated runtime code to the [`output.environment`](/configuration/output/#outputenvironment) capabilities inferred from your `target`. This release adds several capability flags so modern targets get smaller, cleaner runtime code, while older targets keep their exact previous output:
+
+- `let` — emit `let`/`const` instead of `var` where it's safe.
+- `logicalAssignment` — emit `||=` instead of the equivalent `x = x || y` form.
+- `spread` — use `{ ...obj }` and `fn(...args)` instead of `Object.assign` / `concat`.
+- `hasOwn` — use `Object.hasOwn` instead of `Object.prototype.hasOwnProperty.call`.
+- `symbol` — drop the `typeof Symbol !== "undefined"` guard in the namespace helper.
+- `nodeBuiltinModuleGetter` — use `process.getBuiltinModule()` to load Node.js core modules (used by universal builds).
+
+These are normally derived from your `target`; you only set them by hand to override that detection.
+
+### `output.strictModuleResolution`
+
+The runtime guard that throws `MODULE_NOT_FOUND` when a required module id is missing from the bundle now has its own dedicated option, [`output.strictModuleResolution`](/configuration/output/#outputstrictmoduleresolution). It defaults to `true` in development and `false` in production. Previously this guard was tied to `output.pathinfo`; decoupling it lets you, for example, re-enable the check in a production build while debugging.
+
+```js
+// webpack.config.js
+module.exports = {
+  mode: "production",
+  output: {
+    strictModuleResolution: true,
+  },
+};
+```
+
+### `[uniquename]` Template Placeholder
+
+A new `[uniquename]` placeholder (a `[uniqueName]` spelling is also accepted) is available in template paths and resolves to [`output.uniqueName`](/configuration/output/#outputuniquename). It works in `output.filename`, `output.chunkFilename`, CSS `localIdentName`, and the other asset-path templates:
+
+```js
+// webpack.config.js
+module.exports = {
+  output: {
+    uniqueName: "my-app",
+    filename: "[uniquename].[name].js", // -> my-app.main.js
+  },
+};
+```
+
+### Worker Chunk Filenames
+
+You can now name worker chunks independently of regular chunks with [`output.workerChunkFilename`](/configuration/output/#outputworkerchunkfilename), which accepts the same string templates and function form as `output.chunkFilename` and defaults to its value. Entries that webpack creates from `new Worker(new URL(...))` are marked as workers (via a new entry-level `worker` flag) so their output files use it.
+
+```js
+// webpack.config.js
+module.exports = {
+  output: {
+    chunkFilename: "[name].chunk.js",
+    workerChunkFilename: "workers/[name].[contenthash].worker.js",
+  },
+};
+```
+
+## Typed Configuration with `defineConfig`
+
+Webpack now exports a `defineConfig` helper that gives editors type-checking and autocomplete for your configuration without any extra type annotations. It's an identity function (a no-op at runtime that returns the config you pass in), so it works in plain JavaScript configs too, mirroring Vite, Rollup, and Rspack.
+
+```js
+// webpack.config.js
+const { defineConfig } = require("webpack");
+
+module.exports = defineConfig({
+  mode: "none",
+});
+```
+
+It accepts every shape webpack-cli can load: a single configuration object, an array of configurations, a function returning either, an array of such functions, or a `Promise` resolving to any of them.
+
+## Bug Fixes
+
+Several bug fixes have been resolved since version [5.107](https://github.com/webpack/webpack/releases/tag/v5.107.0), along with a large batch of performance improvements across the CSS pipeline, the experimental HTML parser, module concatenation, and the persistent cache. Check the [changelog](https://github.com/webpack/webpack/blob/main/CHANGELOG.md) for all the details.
+
+## Thanks
+
+A big thank you to all our contributors and [sponsors](https://github.com/webpack/webpack?tab=readme-ov-file#sponsoring)
+who made Webpack 5.108 possible. Your support, whether through code contributions, documentation, or financial sponsorship, helps keep Webpack evolving and improving for everyone.