From 82775c346f05884094152c3c5c9c44e92c0b529a Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Sat, 16 May 2026 20:39:10 -0500
Subject: [PATCH 1/6] docs: add blog post for Webpack 5.107 release
 highlighting new HTML module support and CSS improvements

---
 src/content/blog/2026-05-16-webpack-5-107.mdx | 407 ++++++++++++++++++
 1 file changed, 407 insertions(+)
 create mode 100644 src/content/blog/2026-05-16-webpack-5-107.mdx

diff --git a/src/content/blog/2026-05-16-webpack-5-107.mdx b/src/content/blog/2026-05-16-webpack-5-107.mdx
new file mode 100644
index 000000000000..f9049d70e9e7
--- /dev/null
+++ b/src/content/blog/2026-05-16-webpack-5-107.mdx
@@ -0,0 +1,407 @@
+---
+title: Webpack 5.107
+sort: 20260516
+contributors:
+  - bjohansebas
+---
+
+Webpack 5.107 is out, and the headline of this release is the very first step toward handling `.html` files natively in webpack core. For years, building a webpack project with a real HTML entry point has meant pulling in `html-webpack-plugin` and `html-loader`. This release starts replacing both of them with first-class support, in the same way `experiments.css` is gradually replacing `css-loader`, `style-loader`, and `mini-css-extract-plugin`.
+
+The HTML pieces are experimental and live behind a new opt-in flag, but the direction is clear: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML and CSS.
+
+Alongside the HTML work, this release also continues maturing the built-in CSS pipeline, and ships a handful of improvements for tree shaking, deferred imports, and module resolution.
+
+Explore what's new:
+
+- [**HTML Modules (Experimental)**](#html-modules-experimental)
+  - [`experiments.html` Flag](#experimentshtml-flag)
+  - [Inline `<style>` Tags](#inline-style-tags)
+  - [`<script src>` and `<link rel="modulepreload">`](#script-src-and-link-relmodulepreload)
+  - [`webpackIgnore` Magic Comment](#webpackignore-magic-comment)
+- [**CSS Improvements**](#css-improvements)
+  - [Scope Hoisting for CSS Modules](#scope-hoisting-for-css-modules)
+  - [Pure Mode for CSS Modules](#pure-mode-for-css-modules)
+  - [`@value` in URLs and `@import`](#value-in-urls-and-import)
+  - [Multiple Aliases via `exportsConvention`](#multiple-aliases-via-exportsconvention)
+  - [`linkInsert` Hook](#linkinsert-hook)
+- [**JavaScript and ESM**](#javascript-and-esm)
+  - [Anonymous Default Export Naming](#anonymous-default-export-naming)
+  - [Preserving `defer` and `source` Phase on Externals](#preserving-defer-and-source-phase-on-externals)
+  - [`#__NO_SIDE_EFFECTS__` Annotation](#__no_side_effects__-annotation)
+- [**Resolver Updates**](#resolver-updates)
+- [**Bug Fixes**](#bug-fixes)
+
+## HTML Modules (Experimental)
+
+W> **This feature is experimental.** The API, configuration, and behavior may change in any release. Please don't depend on it in production yet. What ships in 5.107 is the foundation for native HTML entry-point support targeted at webpack 6, tracked in issue [#536](https://github.com/webpack/webpack/issues/536).
+
+A real-world webpack setup that needs an HTML entry point has historically required at least two extra dependencies. The first is `html-webpack-plugin`, which generates or emits the HTML file and injects the right bundle URLs into it. The second is `html-loader`, which lets webpack walk through `<img src>`, `<link href>`, `<script src>`, and friends so those references go through the normal resolver and asset pipeline.
+
+Both of these have served the community well for a long time, but they live outside the core. Webpack 5.107 starts bringing that responsibility inward.
+
+### `experiments.html` Flag
+
+Everything else in this section sits behind a single opt-in flag. The new `experiments.html` option registers the `html` module type on `NormalModuleFactory` and turns on the HTML behaviors described below.
+
+```js
+// webpack.config.js
+module.exports = {
+  experiments: {
+    html: true,
+  },
+  entry: "./src/index.html",
+};
+```
+
+With the flag enabled, an `.html` file becomes a valid webpack entry point on its own. No plugin or loader is needed to bring it in. The architecture mirrors `experiments.css`: a single boolean that unlocks an entire pipeline.
+
+### Inline `<style>` Tags
+
+When webpack finds a `<style>` block inside an HTML module, it routes the CSS body through the same CSS pipeline you'd use for a `.css` file. The block is treated as a virtual CSS module with `exportType: "text"`, so any `url()` references and `@import` statements inside the style are resolved relative to the HTML file. Once processing finishes, the transformed CSS is written back into the original `<style>` tag.
+
+```html
+<!-- src/index.html -->
+<!doctype html>
+<html>
+  <head>
+    <style>
+      @import "./reset.css";
+
+      body {
+        background: url("./bg.png");
+      }
+    </style>
+  </head>
+  <body>
+    ...
+  </body>
+</html>
+```
+
+`<style type="text/css">` and `<style>` with no `type` attribute are processed. Anything with a non-CSS `type` is passed through untouched. This covers the inline-style behavior of `html-loader` without needing it in the pipeline.
+
+### `<script src>` and `<link rel="modulepreload">`
+
+The other big chunk of `html-webpack-plugin`'s job is wiring HTML to the bundles webpack emits. In 5.107, that responsibility starts moving into core too. Both `<script src>` and `<link rel="modulepreload">` references inside an HTML module now become real webpack entries, and the emitted chunk URL is rewritten back into the HTML so hashed filenames stay correct.
+
+```html
+<!-- src/index.html -->
+<!doctype html>
+<html>
+  <head>
+    <link rel="modulepreload" href="./preloaded.js" />
+  </head>
+  <body>
+    <script src="./entry.js"></script>
+    <script src="./second.js"></script>
+  </body>
+</html>
+```
+
+A few behaviors are worth knowing about:
+
+- Multiple `<script src>` tags in the same page share a single runtime. Within each group (classic or `type="module"`), the leader holds the runtime and the rest declare `dependOn` on it.
+- `<link rel="modulepreload">` entries stay independent and are never imported by sibling scripts, so they preload without executing, exactly as the spec requires.
+- When `output.module` is enabled, classic `<script src>` tags are auto-upgraded to `<script type="module" src>` so the emitted ES-module chunks load in the right mode.
+- Non-JS script types like `application/ld+json` or `importmap`, as well as data URIs, flow through unchanged and are not bundled as JS.
+
+### `webpackIgnore` Magic Comment
+
+The familiar `webpackIgnore: true` magic comment now works inside HTML modules. Place an HTML comment with the directive right before a tag and webpack will leave that tag's URLs untouched in the output. This is exactly how `html-loader` handles the same case.
+
+```html
+<!doctype html>
+<html>
+  <body>
+    <!-- webpackIgnore: true -->
+    <img src="https://cdn.example.com/logo.png" />
+
+    <!-- webpackIgnore: true -->
+    <script src="/legacy/external.js"></script>
+  </body>
+</html>
+```
+
+The comment value is parsed with the same context the JS and CSS parsers use, so non-boolean values raise an `UnsupportedFeatureWarning`.
+
+## CSS Improvements
+
+### Scope Hoisting for CSS Modules
+
+Module concatenation (also known as scope hoisting) used to be a JavaScript-only optimization. Even with `experiments.css` enabled, CSS Modules pulled into a concatenated bundle still produced separate runtime instances. Starting with 5.107, the same optimization applies to CSS Modules whose export type is `text`, `css-style-sheet`, `style`, or `link`. The result is lower runtime overhead and smaller output in CSS-heavy bundles.
+
+```js
+module.exports = {
+  experiments: { css: true },
+  optimization: {
+    concatenateModules: true,
+  },
+  module: {
+    rules: [
+      {
+        test: /\.css$/,
+        type: "css/module",
+        parser: {
+          exportType: "css-style-sheet",
+        },
+      },
+    ],
+  },
+};
+```
+
+### Pure Mode for CSS Modules
+
+A new `pure` parser option for `css/module` and `css/auto` mirrors the strict pure mode of `postcss-modules-local-by-default`. When enabled, every selector must contain at least one local class or id; otherwise webpack raises a build error. The point is to catch accidentally global selectors in CSS Modules before they make it into production.
+
+```js
+module.exports = {
+  experiments: { css: true },
+  module: {
+    parser: {
+      "css/module": {
+        pure: true,
+      },
+    },
+  },
+};
+```
+
+Two comments offer opt-outs when you need them. The first suppresses the check for a single rule:
+
+```css
+/* cssmodules-pure-ignore */
+a {
+  /* suppressed only for this rule */
+  color: blue;
+}
+```
+
+The second, placed among the leading comments of a file before any rule, disables the check for the entire file:
+
+```css
+/* cssmodules-pure-no-check */
+/* disables pure mode for this file */
+
+a {
+  /* would normally fail under pure mode */
+  color: red;
+}
+```
+
+Nested rules inside a local-bearing ancestor count as pure-compliant, `&` resolves to the parent rule's purity, and `@keyframes` and `@counter-style` bodies are exempt.
+
+### `@value` in URLs and `@import`
+
+CSS Modules `@value` identifiers can now be used as the path argument to `@import` and inside `url()` references. This makes it easy to define shared paths and assets once and reuse them across stylesheets.
+
+```css
+@value path: "./other.module.css";
+@import path;
+
+@value bg: "./image.png";
+
+.a {
+  background: url(bg);
+}
+```
+
+Both quoted (`"./x"`, `'./x'`) and bare (`./x`) forms of the value work. Whichever form you write is unwrapped and resolved as a module request, so the asset flows through the normal webpack resolver and asset pipeline instead of being left as a literal identifier.
+
+### Multiple Aliases via `exportsConvention`
+
+The function form of `generator.exportsConvention` for CSS Modules now accepts `string[]` in addition to `string`. Returning an array exports the local class under every name in the array, matching `css-loader`'s behavior. This is handy when you want to expose multiple aliases for a single class, for example both the original name and an uppercase version.
+
+```js
+module.exports = {
+  experiments: { css: true },
+  module: {
+    generator: {
+      "css/module": {
+        exportsConvention: (name) => [name, name.toUpperCase()],
+      },
+    },
+  },
+};
+```
+
+```js
+// Usage in JS
+import styles from "./button.module.css";
+
+console.log(styles.btn); // hashed class
+console.log(styles.BTN); // same hashed class, uppercase alias
+```
+
+### `linkInsert` Hook
+
+If you've ever wanted to control where webpack inserts a stylesheet `<link>` in the document, you now have a hook for it. `CssLoadingRuntimeModule.getCompilationHooks(compilation)` exposes a new `linkInsert` hook. It receives the default insertion source (`document.head.appendChild(link);`) and the chunk, and returns the JS used to attach the link.
+
+```js
+const webpack = require("webpack");
+
+class MyLinkInsertPlugin {
+  apply(compiler) {
+    compiler.hooks.thisCompilation.tap("MyLinkInsertPlugin", (compilation) => {
+      const hooks =
+        webpack.web.CssLoadingRuntimeModule.getCompilationHooks(compilation);
+
+      // Override the default `document.head.appendChild(link);`
+      hooks.linkInsert.tap(
+        "MyLinkInsertPlugin",
+        (source, chunk) =>
+          'link.setAttribute("data-injected", "true"); document.body.appendChild(link);',
+      );
+    });
+  }
+}
+
+module.exports = {
+  experiments: { css: true },
+  plugins: [new MyLinkInsertPlugin()],
+};
+```
+
+The hook is a `SyncWaterfallHook<[string, Chunk]>`. Return the default `source` to keep the original behavior, or return your own JS to override where (and how) the link is attached.
+
+## JavaScript and ESM
+
+### Anonymous Default Export Naming
+
+Webpack 5.106 introduced a fix-up that sets `.name` to `"default"` for anonymous default exports, matching the ES spec. It works correctly, but it injects unmangleable `Object.defineProperty` calls that inflate the bundle. For library consumers, who rarely rely on `.name === "default"`, that extra runtime helper is pure overhead.
+
+5.107 introduces a new option, `module.parser.javascript.anonymousDefaultExportName`, to control this behavior. It defaults to `true` for applications and `false` for libraries (when `output.library` is set). Apps stay spec-compliant by default; library authors stop paying for the extra runtime helper without having to know about it.
+
+```js
+// input
+export default function () {
+  /* ... */
+}
+
+// with `anonymousDefaultExportName: true` (default for apps)
+// the runtime sets .name = "default" matching native ESM behavior
+```
+
+You can override the default explicitly:
+
+```js
+module.exports = {
+  module: {
+    parser: {
+      javascript: {
+        anonymousDefaultExportName: false,
+      },
+    },
+  },
+};
+```
+
+### Preserving `defer` and `source` Phase on Externals
+
+Webpack now preserves the `defer` and `source` import phase keywords on external dependencies in ESM output, the same way import attributes are already preserved. Previously, the phase keyword was stripped from the emitted statement, so an `import defer * as ns from "x"` against an external lost its deferred semantics in the output.
+
+For static `module` externals, namespace defer imports and single-default source imports are now emitted as native phase syntax at the top of the bundle:
+
+```js
+// webpack.config.js
+module.exports = {
+  output: { module: true },
+  externalsType: "module",
+  externals: { "external-mod": "external-mod" },
+};
+```
+
+```text
+// input
+import defer * as ns from "external-mod";
+import source v from "external-mod";
+
+// emitted output
+import defer * as ns from "external-mod";
+import source v from "external-mod";
+```
+
+For dynamic `import` externals, `import.defer("x")` and `import.source("x")` are emitted directly:
+
+```text
+// input
+const ns = await import.defer("external-mod");
+const src = await import.source("external-mod");
+
+// emitted output
+const ns = await import.defer("external-mod");
+const src = await import.source("external-mod");
+```
+
+One related improvement: the same external imported with two different phases (or attribute sets) no longer collapses into a single `ExternalModule`. Each combination produces its own emit, so neither phase is silently dropped.
+
+### `#__NO_SIDE_EFFECTS__` Annotation
+
+Webpack now supports the [`#__NO_SIDE_EFFECTS__`](https://github.com/javascript-compiler-hints/compiler-notations-spec/blob/main/no-side-effects-notation-spec.md#2-const-variable-declaration) annotation to mark functions as pure for better tree shaking. Calls to functions annotated this way can be eliminated from the bundle when their return value is unused, even if the function body is not statically analyzable as pure.
+
+{/* eslint-disable */}
+
+```js
+// utils.js
+/*#__NO_SIDE_EFFECTS__*/
+export function createLogger(prefix) {
+  return (msg) => console.log(`[${prefix}] ${msg}`);
+}
+
+export function realWork() {
+  // ...
+}
+```
+
+{/* eslint-enable */}
+
+```js
+// app.js
+import { createLogger, realWork } from "./utils";
+
+// dropped, because `createLogger` is annotated and its result is unused
+const unused = createLogger("debug");
+
+realWork();
+```
+
+W> The annotation currently only takes effect **within the module where it is declared**. Cross-module propagation is planned for a future PR.
+
+## Resolver Updates
+
+Webpack now adds `"module-sync"` to the default `conditionNames` for resolver defaults, aligning with Node.js. Node.js exposes the `module-sync` community condition for synchronously-loadable ESM, and this change affects the ESM, CJS, AMD, worker, wasm, and build-dependency resolvers.
+
+Concretely, the resolver defaults now include `module-sync` right before `module` in the condition chain:
+
+```js
+// Before (5.106)
+conditionNames: ["require", "module", "..."]; // CJS deps
+conditionNames: ["import", "module", "..."]; // ESM deps
+
+// After (5.107)
+conditionNames: ["require", "module-sync", "module", "..."];
+conditionNames: ["import", "module-sync", "module", "..."];
+```
+
+This means packages that publish a `module-sync` export condition in their `package.json` will be picked up automatically without any additional configuration:
+
+```json
+{
+  "name": "my-package",
+  "exports": {
+    ".": {
+      "module-sync": "./esm/index.js",
+      "default": "./cjs/index.js"
+    }
+  }
+}
+```
+
+## Bug Fixes
+
+Several bug fixes have been resolved since version [5.106](https://github.com/webpack/webpack/releases/tag/v5.106.0). 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.107 possible. Your support, whether through code contributions, documentation, or financial sponsorship, helps keep Webpack evolving and improving for everyone.

From 115ed38766c1e589e2d094d359785f6c4d66aeca Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Tue, 19 May 2026 08:57:26 -0500
Subject: [PATCH 2/6] docs: update blog post for Webpack 5.107 to include
 experimental TypeScript support and clarify HTML module integration

---
 src/content/blog/2026-05-16-webpack-5-107.mdx | 29 +++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/src/content/blog/2026-05-16-webpack-5-107.mdx b/src/content/blog/2026-05-16-webpack-5-107.mdx
index f9049d70e9e7..62588c9c118f 100644
--- a/src/content/blog/2026-05-16-webpack-5-107.mdx
+++ b/src/content/blog/2026-05-16-webpack-5-107.mdx
@@ -7,9 +7,11 @@ contributors:
 
 Webpack 5.107 is out, and the headline of this release is the very first step toward handling `.html` files natively in webpack core. For years, building a webpack project with a real HTML entry point has meant pulling in `html-webpack-plugin` and `html-loader`. This release starts replacing both of them with first-class support, in the same way `experiments.css` is gradually replacing `css-loader`, `style-loader`, and `mini-css-extract-plugin`.
 
-The HTML pieces are experimental and live behind a new opt-in flag, but the direction is clear: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML and CSS.
+This release also lands experimental TypeScript support that leans on Node.js's built-in type-stripping, so simple TypeScript projects can compile without `ts-loader` or `swc-loader`.
 
-Alongside the HTML work, this release also continues maturing the built-in CSS pipeline, and ships a handful of improvements for tree shaking, deferred imports, and module resolution.
+The HTML and TypeScript pieces are experimental and live behind opt-in flags, but the direction is clear: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML, CSS, and basic TypeScript.
+
+Alongside the experimental work, this release also continues maturing the built-in CSS pipeline, and ships a handful of improvements for tree shaking, deferred imports, and module resolution.
 
 Explore what's new:
 
@@ -18,6 +20,7 @@ Explore what's new:
   - [Inline `<style>` Tags](#inline-style-tags)
   - [`<script src>` and `<link rel="modulepreload">`](#script-src-and-link-relmodulepreload)
   - [`webpackIgnore` Magic Comment](#webpackignore-magic-comment)
+- [**TypeScript Support (Experimental)**](#typescript-support-experimental)
 - [**CSS Improvements**](#css-improvements)
   - [Scope Hoisting for CSS Modules](#scope-hoisting-for-css-modules)
   - [Pure Mode for CSS Modules](#pure-mode-for-css-modules)
@@ -124,6 +127,28 @@ The familiar `webpackIgnore: true` magic comment now works inside HTML modules.
 
 The comment value is parsed with the same context the JS and CSS parsers use, so non-boolean values raise an `UnsupportedFeatureWarning`.
 
+## TypeScript Support (Experimental)
+
+W> **This feature is experimental and depends on a recent Node.js.** It requires Node.js 22.6 or later for the stable `module.stripTypeScriptTypes` API. The transform handles only erasable TypeScript syntax (see limitations below). For anything else, keep using `ts-loader` or `swc-loader`.
+
+Webpack 5.107 adds first-class TypeScript support behind a new `experiments.typescript` flag. With it enabled, webpack compiles `.ts`, `.cts`, and `.mts` files directly through Node.js's built-in [`module.stripTypeScriptTypes`](https://nodejs.org/api/module.html#modulestriptypescripttypescode-options), no external loader required. The flag is also turned on automatically by [`experiments.futureDefaults`](/configuration/experiments/#experimentsfuturedefaults).
+
+```js
+// webpack.config.js
+export default {
+  experiments: {
+    typescript: true,
+  },
+  entry: "./src/index.ts",
+};
+```
+
+Enabling the flag also wires up sensible defaults: rules for `.ts` / `.cts` / `.mts`, `.ts` added to extension resolution before `.js`, `extensionAlias` so `import "./foo.js"` also tries `./foo.ts`, `tsconfig.json` resolution, and the `"typescript"` conditional-exports key for monorepos that ship `.ts` sources.
+
+The transform only **erases types**: no type checking, no JSX / `.tsx`, and no non-erasable syntax (`enum`, `namespace`, parameter-property constructors, decorator metadata). These are the same constraints TypeScript enforces with [`erasableSyntaxOnly`](https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly). For type checking, pair the flag with `tsc --noEmit` or [`fork-ts-checker-webpack-plugin`](https://github.com/TypeStrong/fork-ts-checker-webpack-plugin). For JSX or non-erasable syntax, keep using `ts-loader` or `swc-loader`.
+
+See [`examples/typescript`](https://github.com/webpack/webpack/tree/main/examples/typescript) for the built-in setup and [`examples/typescript-non-erasable`](https://github.com/webpack/webpack/tree/main/examples/typescript-non-erasable) for the `ts-loader` fallback.
+
 ## CSS Improvements
 
 ### Scope Hoisting for CSS Modules

From d4b46ae158014dcc4683b2cb17a480dd0812e1b3 Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Tue, 19 May 2026 09:06:50 -0500
Subject: [PATCH 3/6] docs: refine blog post for Webpack 5.107 to clarify HTML
 module support and TypeScript integration

---
 src/content/blog/2026-05-16-webpack-5-107.mdx | 41 ++++++++++---------
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/src/content/blog/2026-05-16-webpack-5-107.mdx b/src/content/blog/2026-05-16-webpack-5-107.mdx
index 62588c9c118f..a970ca776c29 100644
--- a/src/content/blog/2026-05-16-webpack-5-107.mdx
+++ b/src/content/blog/2026-05-16-webpack-5-107.mdx
@@ -5,11 +5,11 @@ contributors:
   - bjohansebas
 ---
 
-Webpack 5.107 is out, and the headline of this release is the very first step toward handling `.html` files natively in webpack core. For years, building a webpack project with a real HTML entry point has meant pulling in `html-webpack-plugin` and `html-loader`. This release starts replacing both of them with first-class support, in the same way `experiments.css` is gradually replacing `css-loader`, `style-loader`, and `mini-css-extract-plugin`.
+Webpack 5.107 is out. The headline of this release is the first step toward handling `.html` files natively in webpack core: importing an HTML file from JS now resolves its `<img src>`, `<link href>`, inline `<style>`, and `<script src>` references through the normal webpack pipeline, replacing the role `html-loader` has played for years. HTML entry points (the `html-webpack-plugin` part of the story) are not in 5.107 yet, they are planned for the next minor release.
 
 This release also lands experimental TypeScript support that leans on Node.js's built-in type-stripping, so simple TypeScript projects can compile without `ts-loader` or `swc-loader`.
 
-The HTML and TypeScript pieces are experimental and live behind opt-in flags, but the direction is clear: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML, CSS, and basic TypeScript.
+Both pieces are experimental and live behind opt-in flags, but the direction is clear: you should eventually be able to build a complete web app with zero extra loaders or plugins for HTML, CSS, and basic TypeScript.
 
 Alongside the experimental work, this release also continues maturing the built-in CSS pipeline, and ships a handful of improvements for tree shaking, deferred imports, and module resolution.
 
@@ -36,11 +36,11 @@ Explore what's new:
 
 ## HTML Modules (Experimental)
 
-W> **This feature is experimental.** The API, configuration, and behavior may change in any release. Please don't depend on it in production yet. What ships in 5.107 is the foundation for native HTML entry-point support targeted at webpack 6, tracked in issue [#536](https://github.com/webpack/webpack/issues/536).
+W> **This feature is experimental and partial.** Webpack 5.107 only implements the `html-loader` side of the story: importing an HTML file from JavaScript runs its tag references through the webpack pipeline. **HTML entry points** (using a `.html` file directly as `entry`, the `html-webpack-plugin` part) are **not supported yet** and are planned for the next minor release. The full story is tracked in issue [#536](https://github.com/webpack/webpack/issues/536).
 
 A real-world webpack setup that needs an HTML entry point has historically required at least two extra dependencies. The first is `html-webpack-plugin`, which generates or emits the HTML file and injects the right bundle URLs into it. The second is `html-loader`, which lets webpack walk through `<img src>`, `<link href>`, `<script src>`, and friends so those references go through the normal resolver and asset pipeline.
 
-Both of these have served the community well for a long time, but they live outside the core. Webpack 5.107 starts bringing that responsibility inward.
+Both of these have served the community well for a long time, but they live outside the core. Webpack 5.107 starts bringing the `html-loader` side of that work inward.
 
 ### `experiments.html` Flag
 
@@ -52,18 +52,26 @@ module.exports = {
   experiments: {
     html: true,
   },
-  entry: "./src/index.html",
 };
 ```
 
-With the flag enabled, an `.html` file becomes a valid webpack entry point on its own. No plugin or loader is needed to bring it in. The architecture mirrors `experiments.css`: a single boolean that unlocks an entire pipeline.
+You then import the HTML file from JavaScript. The default export is the processed HTML as a string, with all asset references resolved through webpack:
+
+```js
+// src/index.js
+import page from "./page.html";
+
+document.documentElement.innerHTML = page;
+```
+
+This is the same shape `html-loader` produces, so existing code that imports HTML should keep working. The pipeline does the work the loader used to do: tag references are resolved, hashed filenames are rewritten back into the HTML string, and the result lands in your JS bundle. Using an `.html` file directly as a webpack `entry` is **not** supported in 5.107.
 
 ### Inline `<style>` Tags
 
-When webpack finds a `<style>` block inside an HTML module, it routes the CSS body through the same CSS pipeline you'd use for a `.css` file. The block is treated as a virtual CSS module with `exportType: "text"`, so any `url()` references and `@import` statements inside the style are resolved relative to the HTML file. Once processing finishes, the transformed CSS is written back into the original `<style>` tag.
+When webpack finds a `<style>` block inside an HTML module, it routes the CSS body through the same CSS pipeline you'd use for a `.css` file. The block is treated as a virtual CSS module with `exportType: "text"`, so any `url()` references and `@import` statements inside the style are resolved relative to the HTML file. Once processing finishes, the transformed CSS is written back into the original `<style>` tag in the emitted HTML string.
 
 ```html
-<!-- src/index.html -->
+<!-- src/page.html -->
 <!doctype html>
 <html>
   <head>
@@ -85,10 +93,10 @@ When webpack finds a `<style>` block inside an HTML module, it routes the CSS bo
 
 ### `<script src>` and `<link rel="modulepreload">`
 
-The other big chunk of `html-webpack-plugin`'s job is wiring HTML to the bundles webpack emits. In 5.107, that responsibility starts moving into core too. Both `<script src>` and `<link rel="modulepreload">` references inside an HTML module now become real webpack entries, and the emitted chunk URL is rewritten back into the HTML so hashed filenames stay correct.
+`<script src>` and `<link rel="modulepreload">` references inside an HTML module become real webpack entries, and the emitted chunk URL is rewritten back into the HTML string so hashed filenames stay correct.
 
 ```html
-<!-- src/index.html -->
+<!-- src/page.html -->
 <!doctype html>
 <html>
   <head>
@@ -113,16 +121,11 @@ A few behaviors are worth knowing about:
 The familiar `webpackIgnore: true` magic comment now works inside HTML modules. Place an HTML comment with the directive right before a tag and webpack will leave that tag's URLs untouched in the output. This is exactly how `html-loader` handles the same case.
 
 ```html
-<!doctype html>
-<html>
-  <body>
-    <!-- webpackIgnore: true -->
-    <img src="https://cdn.example.com/logo.png" />
+<!-- webpackIgnore: true -->
+<img src="https://cdn.example.com/logo.png" />
 
-    <!-- webpackIgnore: true -->
-    <script src="/legacy/external.js"></script>
-  </body>
-</html>
+<!-- webpackIgnore: true -->
+<script src="/legacy/external.js"></script>
 ```
 
 The comment value is parsed with the same context the JS and CSS parsers use, so non-boolean values raise an `UnsupportedFeatureWarning`.

From 19df9b849053506e74282f10b59feb67583cdb7b Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Tue, 19 May 2026 09:11:21 -0500
Subject: [PATCH 4/6] docs: enhance blog post for Webpack 5.107 to include
 details on inline `<script>` tag support

---
 src/content/blog/2026-05-16-webpack-5-107.mdx | 28 +++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/src/content/blog/2026-05-16-webpack-5-107.mdx b/src/content/blog/2026-05-16-webpack-5-107.mdx
index a970ca776c29..6f9642cdcf65 100644
--- a/src/content/blog/2026-05-16-webpack-5-107.mdx
+++ b/src/content/blog/2026-05-16-webpack-5-107.mdx
@@ -18,6 +18,7 @@ Explore what's new:
 - [**HTML Modules (Experimental)**](#html-modules-experimental)
   - [`experiments.html` Flag](#experimentshtml-flag)
   - [Inline `<style>` Tags](#inline-style-tags)
+  - [Inline `<script>` Tags](#inline-script-tags)
   - [`<script src>` and `<link rel="modulepreload">`](#script-src-and-link-relmodulepreload)
   - [`webpackIgnore` Magic Comment](#webpackignore-magic-comment)
 - [**TypeScript Support (Experimental)**](#typescript-support-experimental)
@@ -91,6 +92,33 @@ When webpack finds a `<style>` block inside an HTML module, it routes the CSS bo
 
 `<style type="text/css">` and `<style>` with no `type` attribute are processed. Anything with a non-CSS `type` is passed through untouched. This covers the inline-style behavior of `html-loader` without needing it in the pipeline.
 
+### Inline `<script>` Tags
+
+Inline `<script>` bodies are routed through the same entry pipeline that already handles `<script src>`. Each `<script>` body becomes its own webpack entry: classic inline scripts are bundled as CommonJS, and `<script type="module">` bodies are bundled as ESM. The tag in the emitted HTML is rewritten to `<script src="…">` pointing at the generated chunk, with the body cleared.
+
+```html
+<!-- src/page.html -->
+<!doctype html>
+<html>
+  <body>
+    <script type="module">
+      import { greet } from "./lib.js";
+      greet("world");
+    </script>
+
+    <script>
+      console.log("classic inline script");
+    </script>
+  </body>
+</html>
+```
+
+The same behaviors that apply to external `<script src>` apply here too:
+
+- When `output.module` is enabled, classic inline `<script>` tags are auto-upgraded to `type="module"`, matching the auto-upgrade for `<script src>`.
+- `webpackIgnore` works on inline `<script>` tags as well, leaving the original body untouched.
+- Non-JS `type` values like `application/ld+json` and `importmap` pass through unchanged.
+
 ### `<script src>` and `<link rel="modulepreload">`
 
 `<script src>` and `<link rel="modulepreload">` references inside an HTML module become real webpack entries, and the emitted chunk URL is rewritten back into the HTML string so hashed filenames stay correct.

From 3719c19fe450b1ecbf5b8b7b78360a19f64579b0 Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Tue, 19 May 2026 09:13:17 -0500
Subject: [PATCH 5/6] docs: change date

---
 ...026-05-16-webpack-5-107.mdx => 2026-05-19-webpack-5-107.mdx} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename src/content/blog/{2026-05-16-webpack-5-107.mdx => 2026-05-19-webpack-5-107.mdx} (99%)

diff --git a/src/content/blog/2026-05-16-webpack-5-107.mdx b/src/content/blog/2026-05-19-webpack-5-107.mdx
similarity index 99%
rename from src/content/blog/2026-05-16-webpack-5-107.mdx
rename to src/content/blog/2026-05-19-webpack-5-107.mdx
index 6f9642cdcf65..6b3983426759 100644
--- a/src/content/blog/2026-05-16-webpack-5-107.mdx
+++ b/src/content/blog/2026-05-19-webpack-5-107.mdx
@@ -1,6 +1,6 @@
 ---
 title: Webpack 5.107
-sort: 20260516
+sort: 20260519
 contributors:
   - bjohansebas
 ---

From d2e3e1982a5a47627261fe496f1d77368f5ffd07 Mon Sep 17 00:00:00 2001
From: Sebastian Beltran <bjohansebas@gmail.com>
Date: Tue, 19 May 2026 09:18:23 -0500
Subject: [PATCH 6/6] docs: add `orderModules` hook documentation to enhance
 CSS module ordering

---
 src/content/blog/2026-05-19-webpack-5-107.mdx | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/src/content/blog/2026-05-19-webpack-5-107.mdx b/src/content/blog/2026-05-19-webpack-5-107.mdx
index 6b3983426759..c92b2e7a2927 100644
--- a/src/content/blog/2026-05-19-webpack-5-107.mdx
+++ b/src/content/blog/2026-05-19-webpack-5-107.mdx
@@ -28,6 +28,7 @@ Explore what's new:
   - [`@value` in URLs and `@import`](#value-in-urls-and-import)
   - [Multiple Aliases via `exportsConvention`](#multiple-aliases-via-exportsconvention)
   - [`linkInsert` Hook](#linkinsert-hook)
+  - [`orderModules` Hook](#ordermodules-hook)
 - [**JavaScript and ESM**](#javascript-and-esm)
   - [Anonymous Default Export Naming](#anonymous-default-export-naming)
   - [Preserving `defer` and `source` Phase on Externals](#preserving-defer-and-source-phase-on-externals)
@@ -320,6 +321,43 @@ module.exports = {
 
 The hook is a `SyncWaterfallHook<[string, Chunk]>`. Return the default `source` to keep the original behavior, or return your own JS to override where (and how) the link is attached.
 
+### `orderModules` Hook
+
+When a chunk pulls in CSS from several files, webpack's default ordering is a topological sort of their import graph. That's the right call in most cases, but on real-world projects the import graph can be ambiguous enough to trigger the "Conflicting order between CSS …" warning, with no clean way out short of restructuring imports.
+
+A new `orderModules` hook on `CssModulesPlugin.getCompilationHooks(compilation)` gives plugin authors a deterministic escape hatch. It runs once per CSS source type (`CSS_IMPORT_TYPE` and `CSS_TYPE`) with the chunk's modules pre-sorted by full module name. Return an ordered `Module[]` to override the default, or return `undefined` to fall through to webpack's existing import-order topological sort.
+
+```js
+const webpack = require("webpack");
+
+class CssOrderByPathPlugin {
+  apply(compiler) {
+    compiler.hooks.thisCompilation.tap(
+      "CssOrderByPathPlugin",
+      (compilation) => {
+        const hooks =
+          webpack.css.CssModulesPlugin.getCompilationHooks(compilation);
+
+        // Modules arrive pre-sorted by full module name; return as-is for
+        // a deterministic file-path order that side-steps the conflicting
+        // order warning.
+        hooks.orderModules.tap(
+          "CssOrderByPathPlugin",
+          (_chunk, modules) => modules,
+        );
+      },
+    );
+  }
+}
+
+module.exports = {
+  experiments: { css: true },
+  plugins: [new CssOrderByPathPlugin()],
+};
+```
+
+The hook is a `SyncBailHook<[Chunk, Module[], Compilation], Module[] | undefined>`. The first tap to return a non-`undefined` value wins.
+
 ## JavaScript and ESM
 
 ### Anonymous Default Export Naming