From 01f5a3e47a85d68bbe5cb76ca617aff0b43df532 Mon Sep 17 00:00:00 2001
From: avivkeller <me@aviv.sh>
Date: Thu, 18 Jun 2026 17:37:44 -0600
Subject: [PATCH 1/2] chore(copying): copy files from webpack.js.org: guides

---
 .../guides/core-workflows/asset-management.md | 828 ++++++++++++++++++
 pages/guides/core-workflows/asset-modules.md  | 566 ++++++++++++
 .../development/hot-module-replacement.md     | 376 ++++++++
 .../core-workflows/development/index.md       | 422 +++++++++
 .../core-workflows/development/vagrant.md     | 107 +++
 .../core-workflows/environment-variables.md   |  46 +
 .../core-workflows/output-management.md       | 225 +++++
 pages/guides/core-workflows/production.md     | 201 +++++
 .../getting-started/concepts/configuration.md |  84 ++
 .../concepts/dependency-graph.md              |  17 +
 .../getting-started/concepts/entry-points.md  | 223 +++++
 .../concepts/hot-module-replacement.md        |  64 ++
 .../guides/getting-started/concepts/index.md  | 162 ++++
 .../getting-started/concepts/loaders.md       | 122 +++
 .../getting-started/concepts/manifest.md      |  37 +
 .../concepts/module-federation.md             | 373 ++++++++
 .../concepts/module-resolution.md             |  74 ++
 .../getting-started/concepts/modules.md       |  49 ++
 .../guides/getting-started/concepts/output.md |  68 ++
 .../getting-started/concepts/plugins.md       |  90 ++
 .../getting-started/concepts/targets.md       |  79 ++
 .../concepts/under-the-hood.md                | 122 +++
 .../getting-started/concepts/why-webpack.md   |  47 +
 pages/guides/getting-started/index.md         | 393 +++++++++
 .../getting-started/installing-webpack.md     |  69 ++
 pages/guides/index.md                         |   3 +
 pages/guides/migration/index.md               |   7 +
 pages/guides/migration/to-v3.md               | 589 +++++++++++++
 pages/guides/migration/to-v4.md               | 147 ++++
 pages/guides/migration/to-v5.md               | 339 +++++++
 pages/guides/modern-web/index.md              | 189 ++++
 pages/guides/modern-web/native-css.md         | 250 ++++++
 .../modern-web/progressive-web-application.md | 139 +++
 pages/guides/modern-web/web-workers.md        | 119 +++
 .../dependency-management.md                  | 143 +++
 .../ecma-script-modules.md                    | 210 +++++
 .../entry-advanced.md                         |  71 ++
 .../package-exports.md                        | 603 +++++++++++++
 .../modules-and-dependencies/shimming.md      | 461 ++++++++++
 .../guides/optimization/build-performance.md  | 249 ++++++
 pages/guides/optimization/caching.md          | 328 +++++++
 .../optimization/code-splitting/index.md      | 461 ++++++++++
 .../code-splitting/lazy-loading.md            | 237 +++++
 pages/guides/optimization/tree-shaking.md     | 576 ++++++++++++
 pages/guides/site.json                        | 209 +++++
 .../authoring-libraries.md                    | 318 +++++++
 .../content-security-policy.md                |  40 +
 .../tooling-and-integration/integrations.md   | 116 +++
 .../tooling-and-integration/typescript.md     | 360 ++++++++
 pages/site.mjs                                |   2 +
 50 files changed, 11010 insertions(+)
 create mode 100644 pages/guides/core-workflows/asset-management.md
 create mode 100644 pages/guides/core-workflows/asset-modules.md
 create mode 100644 pages/guides/core-workflows/development/hot-module-replacement.md
 create mode 100644 pages/guides/core-workflows/development/index.md
 create mode 100644 pages/guides/core-workflows/development/vagrant.md
 create mode 100644 pages/guides/core-workflows/environment-variables.md
 create mode 100644 pages/guides/core-workflows/output-management.md
 create mode 100644 pages/guides/core-workflows/production.md
 create mode 100644 pages/guides/getting-started/concepts/configuration.md
 create mode 100644 pages/guides/getting-started/concepts/dependency-graph.md
 create mode 100644 pages/guides/getting-started/concepts/entry-points.md
 create mode 100644 pages/guides/getting-started/concepts/hot-module-replacement.md
 create mode 100644 pages/guides/getting-started/concepts/index.md
 create mode 100644 pages/guides/getting-started/concepts/loaders.md
 create mode 100644 pages/guides/getting-started/concepts/manifest.md
 create mode 100644 pages/guides/getting-started/concepts/module-federation.md
 create mode 100644 pages/guides/getting-started/concepts/module-resolution.md
 create mode 100644 pages/guides/getting-started/concepts/modules.md
 create mode 100644 pages/guides/getting-started/concepts/output.md
 create mode 100644 pages/guides/getting-started/concepts/plugins.md
 create mode 100644 pages/guides/getting-started/concepts/targets.md
 create mode 100644 pages/guides/getting-started/concepts/under-the-hood.md
 create mode 100644 pages/guides/getting-started/concepts/why-webpack.md
 create mode 100644 pages/guides/getting-started/index.md
 create mode 100644 pages/guides/getting-started/installing-webpack.md
 create mode 100644 pages/guides/index.md
 create mode 100644 pages/guides/migration/index.md
 create mode 100644 pages/guides/migration/to-v3.md
 create mode 100644 pages/guides/migration/to-v4.md
 create mode 100644 pages/guides/migration/to-v5.md
 create mode 100644 pages/guides/modern-web/index.md
 create mode 100644 pages/guides/modern-web/native-css.md
 create mode 100644 pages/guides/modern-web/progressive-web-application.md
 create mode 100644 pages/guides/modern-web/web-workers.md
 create mode 100644 pages/guides/modules-and-dependencies/dependency-management.md
 create mode 100644 pages/guides/modules-and-dependencies/ecma-script-modules.md
 create mode 100644 pages/guides/modules-and-dependencies/entry-advanced.md
 create mode 100644 pages/guides/modules-and-dependencies/package-exports.md
 create mode 100644 pages/guides/modules-and-dependencies/shimming.md
 create mode 100644 pages/guides/optimization/build-performance.md
 create mode 100644 pages/guides/optimization/caching.md
 create mode 100644 pages/guides/optimization/code-splitting/index.md
 create mode 100644 pages/guides/optimization/code-splitting/lazy-loading.md
 create mode 100644 pages/guides/optimization/tree-shaking.md
 create mode 100644 pages/guides/site.json
 create mode 100644 pages/guides/tooling-and-integration/authoring-libraries.md
 create mode 100644 pages/guides/tooling-and-integration/content-security-policy.md
 create mode 100644 pages/guides/tooling-and-integration/integrations.md
 create mode 100644 pages/guides/tooling-and-integration/typescript.md

diff --git a/pages/guides/core-workflows/asset-management.md b/pages/guides/core-workflows/asset-management.md
new file mode 100644
index 00000000..14f52c12
--- /dev/null
+++ b/pages/guides/core-workflows/asset-management.md
@@ -0,0 +1,828 @@
+---
+authors: skipjack,michael-ciniawsky,TheDutchCoder,sudarsangp,chenxsan,EugeneHlushko,AnayaDesign,wizardofhogwarts,astonizer,snitin315,Brennvo,mr-baraiya,avivkeller
+---
+
+# Asset Management
+
+If you've followed the guides from the beginning, you now have a small project that prints "Hello webpack". The next step is to bring in other kinds of assets, such as images, and see how webpack handles them.
+
+Before webpack, front-end developers relied on tools like [grunt](https://gruntjs.com/) and [gulp](https://gulpjs.com/) to process assets and copy them from a `/src` folder into a `/dist` or `/build` directory. JavaScript modules followed the same approach, but webpack takes it further: it **dynamically bundles** every dependency, building what's known as a [dependency graph](#TODO[/concepts/dependency-graph]). This is powerful because each module now _explicitly declares its dependencies_, which lets webpack skip anything that isn't actually used.
+
+One of webpack's nicest features is that you can _import almost any type of file_, not just JavaScript, as long as there's a loader or built-in [Asset Modules](#TODO[/guides/asset-modules/]) support for it. That means the benefits you get with JavaScript, like explicit dependencies, apply to everything you use to build a site or web app. We'll begin with CSS, since that setup is probably already familiar to you.
+
+## Setup
+
+First, make a small change to the project before we begin.
+
+```diff displayName="dist/index.html"
+ <!DOCTYPE html>
+ <html>
+   <head>
+     <meta charset="utf-8" />
+-    <title>Getting Started</title>
++    <title>Asset Management</title>
+   </head>
+   <body>
+-    <script src="main.js"></script>
++    <script src="bundle.js"></script>
+   </body>
+ </html>
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+-    filename: 'main.js',
++    filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+ };
+```
+
+## Loading CSS
+
+To `import` a CSS file from within a JavaScript module, install the [style-loader](#TODO[/loaders/style-loader]) and [css-loader](#TODO[/loaders/css-loader]), then add them to your [`module` configuration](#TODO[/configuration/module]):
+
+```bash
+npm install --save-dev style-loader css-loader
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
++  module: {
++    rules: [
++      {
++        test: /\.css$/i,
++        use: ['style-loader', 'css-loader'],
++      },
++    ],
++  },
+ };
+```
+
+Loaders can be chained together, with each loader in the chain transforming the resource it receives. The chain runs in reverse order, from right to left.
+
+For example, consider the following rule:
+
+```js
+export default {
+  module: {
+    rules: [
+      {
+        test: /\.scss$/i,
+        use: ['postcss-loader', 'sass-loader'],
+      },
+    ],
+  },
+};
+```
+
+Although `postcss-loader` is listed before `sass-loader` in the `use` array, webpack executes `sass-loader` first to compile Sass into CSS, then runs `postcss-loader` on the result. If this order isn't respected, webpack may throw errors.
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
+   ├── /dist
+   │   ├── bundle.js
+   │   └── index.html
+   ├── /src
++  │   ├── style.css
+   │   └── index.js
+   └── /node_modules
+```
+
+```css displayName="src/style.css"
+.hello {
+  color: red;
+}
+```
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
++import './style.css';
+
+ function component() {
+   const element = document.createElement('div');
+
+   // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++  element.classList.add('hello');
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Now run the build command:
+
+```bash
+$ npm run build
+
+...
+[webpack-cli] Compilation finished
+asset bundle.js 72.6 KiB [emitted] [minimized] (name: main) 1 related asset
+runtime modules 1000 bytes 5 modules
+orphan modules 326 bytes [orphan] 1 module
+cacheable modules 539 KiB
+  modules by path ./node_modules/ 538 KiB
+    ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+    ./node_modules/style-loader/dist/runtime/injectStylesIntoStyleTag.js 6.67 KiB [built] [code generated]
+    ./node_modules/css-loader/dist/runtime/api.js 1.57 KiB [built] [code generated]
+  modules by path ./src/ 965 bytes
+    ./src/index.js + 1 modules 639 bytes [built] [code generated]
+    ./node_modules/css-loader/dist/cjs.js!./src/style.css 326 bytes [built] [code generated]
+webpack 5.x.x compiled successfully in 2231 ms
+```
+
+Open `dist/index.html` in your browser again and you should see `Hello webpack` styled in red. To check what webpack did, inspect the page rather than viewing the page source; the source won't reflect the result because the `<style>` tag is created dynamically by JavaScript. Look at the page's head tags, and you should find the style block we imported in `index.js`.
+
+Note that you can, and usually should, [minimize CSS](#TODO[/plugins/mini-css-extract-plugin/#minimizing-for-production]) for faster load times in production. On top of that, loaders exist for just about every flavor of CSS you can think of, including [postcss](#TODO[/loaders/postcss-loader]), [sass](#TODO[/loaders/sass-loader]), and [less](#TODO[/loaders/less-loader]).
+
+## Loading Images
+
+Now that CSS is in place, what about images such as backgrounds and icons? Since webpack 5, the built-in [Asset Modules](#TODO[/guides/asset-modules/]) make it easy to handle these as well:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: /\.css$/i,
+         use: ['style-loader', 'css-loader'],
+       },
++      {
++        test: /\.(png|svg|jpg|jpeg|gif)$/i,
++        type: 'asset/resource',
++      },
+     ],
+   },
+ };
+```
+
+Now, when you write `import MyImage from './my-image.png'`, the image is processed and added to your `output` directory, and the `MyImage` variable holds its final URL after processing. When you use the [css-loader](#TODO[/loaders/css-loader]) as shown above, the same thing happens for `url('./my-image.png')` inside your CSS: the loader recognizes the local file and replaces the `'./my-image.png'` path with the final path to the image in your `output` directory. The [html-loader](#TODO[/loaders/html-loader]) handles `<img src="./my-image.png" />` the same way.
+
+Let's add an image to the project to see this in action. You can use any image you like.
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
+   ├── /dist
+   │   ├── bundle.js
+   │   └── index.html
+   ├── /src
++  │   ├── icon.png
+   │   ├── style.css
+   │   └── index.js
+   └── /node_modules
+```
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
+ import './style.css';
++import Icon from './icon.png';
+
+ function component() {
+   const element = document.createElement('div');
+
+   // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+   element.classList.add('hello');
+
++  // Add the image to our existing div.
++  const myIcon = new Image();
++  myIcon.src = Icon;
++
++  element.appendChild(myIcon);
++
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+```diff displayName="src/style.css"
+ .hello {
+   color: red;
++  background: url('./icon.png');
+ }
+```
+
+Create a new build and open `index.html` again:
+
+```bash
+$ npm run build
+
+...
+[webpack-cli] Compilation finished
+assets by status 9.88 KiB [cached] 1 asset
+asset bundle.js 73.4 KiB [emitted] [minimized] (name: main) 1 related asset
+runtime modules 1.82 KiB 6 modules
+orphan modules 326 bytes [orphan] 1 module
+cacheable modules 540 KiB (javascript) 9.88 KiB (asset)
+  modules by path ./node_modules/ 539 KiB
+    modules by path ./node_modules/css-loader/dist/runtime/*.js 2.38 KiB
+      ./node_modules/css-loader/dist/runtime/api.js 1.57 KiB [built] [code generated]
+      ./node_modules/css-loader/dist/runtime/getUrl.js 830 bytes [built] [code generated]
+    ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+    ./node_modules/style-loader/dist/runtime/injectStylesIntoStyleTag.js 6.67 KiB [built] [code generated]
+  modules by path ./src/ 1.45 KiB (javascript) 9.88 KiB (asset)
+    ./src/index.js + 1 modules 794 bytes [built] [code generated]
+    ./src/icon.png 42 bytes (javascript) 9.88 KiB (asset) [built] [code generated]
+    ./node_modules/css-loader/dist/cjs.js!./src/style.css 648 bytes [built] [code generated]
+webpack 5.x.x compiled successfully in 1972 ms
+```
+
+If everything worked, you should see your icon as a repeating background and an `img` element next to the `Hello webpack` text. Inspect that element and you'll notice the filename has changed to something like `29822eaa871e8eadeaa4.png`, which means webpack found the file in the `src` folder and processed it.
+
+## Loading Fonts
+
+What about other assets like fonts? Asset Modules output any file you load through them to your build directory, so they work for any kind of file, fonts included. Let's update `webpack.config.js` to handle font files:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: /\.css$/i,
+         use: ['style-loader', 'css-loader'],
+       },
+       {
+         test: /\.(png|svg|jpg|jpeg|gif)$/i,
+         type: 'asset/resource',
+       },
++      {
++        test: /\.(woff|woff2|eot|ttf|otf)$/i,
++        type: 'asset/resource',
++      },
+     ],
+   },
+ };
+```
+
+Add some font files to your project:
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
+   ├── /dist
+   │   ├── bundle.js
+   │   └── index.html
+   ├── /src
++  │   ├── my-font.woff
++  │   ├── my-font.woff2
+   │   ├── icon.png
+   │   ├── style.css
+   │   └── index.js
+   └── /node_modules
+```
+
+With the loader configured and the fonts in place, you can reference them through an `@font-face` declaration. webpack picks up the local `url(...)` directive just as it did with the image:
+
+```diff displayName="src/style.css"
++@font-face {
++  font-family: 'MyFont';
++  src: url('./my-font.woff2') format('woff2'),
++    url('./my-font.woff') format('woff');
++  font-weight: 600;
++  font-style: normal;
++}
++
+ .hello {
+   color: red;
++  font-family: 'MyFont';
+   background: url('./icon.png');
+ }
+```
+
+Run a new build and see whether webpack handled the fonts:
+
+```bash
+$ npm run build
+
+...
+[webpack-cli] Compilation finished
+assets by status 9.88 KiB [cached] 1 asset
+assets by info 33.2 KiB [immutable]
+  asset 55055dbfc7c6a83f60ba.woff 18.8 KiB [emitted] [immutable] [from: src/my-font.woff] (auxiliary name: main)
+  asset 8f717b802eaab4d7fb94.woff2 14.5 KiB [emitted] [immutable] [from: src/my-font.woff2] (auxiliary name: main)
+asset bundle.js 73.7 KiB [emitted] [minimized] (name: main) 1 related asset
+runtime modules 1.82 KiB 6 modules
+orphan modules 326 bytes [orphan] 1 module
+cacheable modules 541 KiB (javascript) 43.1 KiB (asset)
+  javascript modules 541 KiB
+    modules by path ./node_modules/ 539 KiB
+      modules by path ./node_modules/css-loader/dist/runtime/*.js 2.38 KiB 2 modules
+      ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+      ./node_modules/style-loader/dist/runtime/injectStylesIntoStyleTag.js 6.67 KiB [built] [code generated]
+    modules by path ./src/ 1.98 KiB
+      ./src/index.js + 1 modules 794 bytes [built] [code generated]
+      ./node_modules/css-loader/dist/cjs.js!./src/style.css 1.21 KiB [built] [code generated]
+  asset modules 126 bytes (javascript) 43.1 KiB (asset)
+    ./src/icon.png 42 bytes (javascript) 9.88 KiB (asset) [built] [code generated]
+    ./src/my-font.woff2 42 bytes (javascript) 14.5 KiB (asset) [built] [code generated]
+    ./src/my-font.woff 42 bytes (javascript) 18.8 KiB (asset) [built] [code generated]
+webpack 5.x.x compiled successfully in 2142 ms
+```
+
+Open `dist/index.html` again and check whether the `Hello webpack` text now uses the new font. If everything went well, you should see the change.
+
+## Loading Data
+
+Another useful kind of asset is data, such as JSON, CSV, TSV, and XML files. JSON support is built in, much like in Node.js, so `import Data from './data.json'` works out of the box. For CSV, TSV, and XML, you can use the [csv-loader](https://github.com/theplatapi/csv-loader) and [xml-loader](https://github.com/gisikw/xml-loader). Let's set up all three:
+
+```bash
+npm install --save-dev csv-loader xml-loader
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: /\.css$/i,
+         use: ['style-loader', 'css-loader'],
+       },
+       {
+         test: /\.(png|svg|jpg|jpeg|gif)$/i,
+         type: 'asset/resource',
+       },
+       {
+         test: /\.(woff|woff2|eot|ttf|otf)$/i,
+         type: 'asset/resource',
+       },
++      {
++        test: /\.(csv|tsv)$/i,
++        use: ['csv-loader'],
++      },
++      {
++        test: /\.xml$/i,
++        use: ['xml-loader'],
++      },
+     ],
+   },
+ };
+```
+
+Add some data files to your project:
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
+   ├── /dist
+   │   ├── bundle.js
+   │   └── index.html
+   ├── /src
++  │   ├── data.xml
++  │   ├── data.csv
+   │   ├── my-font.woff
+   │   ├── my-font.woff2
+   │   ├── icon.png
+   │   ├── style.css
+   │   └── index.js
+   └── /node_modules
+```
+
+```xml displayName="src/data.xml"
+<?xml version="1.0" encoding="UTF-8"?>
+<note>
+  <to>Mary</to>
+  <from>John</from>
+  <heading>Reminder</heading>
+  <body>Call Cindy on Tuesday</body>
+</note>
+```
+
+```csv displayName="src/data.csv"
+to,from,heading,body
+Mary,John,Reminder,Call Cindy on Tuesday
+Zoe,Bill,Reminder,Buy orange juice
+Autumn,Lindsey,Letter,I miss you
+```
+
+You can now `import` any of these four data types (JSON, CSV, TSV, XML), and the `Data` variable you import will hold parsed JSON ready for use:
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
+ import './style.css';
+ import Icon from './icon.png';
++import Data from './data.xml';
++import Notes from './data.csv';
+
+ function component() {
+   const element = document.createElement('div');
+
+   // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+   element.classList.add('hello');
+
+   // Add the image to our existing div.
+   const myIcon = new Image();
+   myIcon.src = Icon;
+
+   element.appendChild(myIcon);
+
++  console.log(Data);
++  console.log(Notes);
++
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Re-run `npm run build` and open `dist/index.html`. Check the console in your developer tools, and you should see your imported data logged there.
+
+> [!TIP]
+> This is especially handy when building a data visualization with a tool like [d3](https://github.com/d3). Instead of making an Ajax request and parsing the data at runtime, you can load it into your module during the build so the parsed data is ready the moment the module reaches the browser.
+
+> [!WARNING]
+> Only the default export of JSON modules can be used without a warning.
+
+```js
+// No warning
+import data from './data.json';
+```
+
+```js
+// Warning shown, this is not allowed by the spec.
+import { foo } from './data.json';
+```
+
+### Customize parser of JSON modules
+
+You can import `toml`, `yaml`, or `json5` files as JSON modules by supplying a [custom parser](#TODO[/configuration/module/#ruleparserparse]) instead of a dedicated webpack loader.
+
+Suppose you have `data.toml`, `data.yaml`, and `data.json5` files in the `src` folder:
+
+```toml displayName="src/data.toml"
+title = "TOML Example"
+
+[owner]
+name = "Tom Preston-Werner"
+organization = "GitHub"
+bio = "GitHub Cofounder & CEO\nLikes tater tots and beer."
+dob = 1979-05-27T07:32:00Z
+```
+
+```yaml displayName="src/data.yaml"
+title: YAML Example
+owner:
+  name: Tom Preston-Werner
+  organization: GitHub
+  bio: |-
+    GitHub Cofounder & CEO
+    Likes tater tots and beer.
+  dob: 1979-05-27T07:32:00.000Z
+```
+
+```json5 displayName="src/data.json5"
+{
+  // comment
+  title: 'JSON5 Example',
+  owner: {
+    name: 'Tom Preston-Werner',
+    organization: 'GitHub',
+    bio: 'GitHub Cofounder & CEO\n\
+Likes tater tots and beer.',
+    dob: '1979-05-27T07:32:00.000Z',
+  },
+}
+```
+
+First install the `toml`, `yamljs`, and `json5` packages:
+
+```bash
+npm install toml yamljs json5 --save-dev
+```
+
+Then configure them in your webpack configuration:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
++import toml from 'toml';
++import yaml from 'yamljs';
++import json5 from 'json5';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: /\.css$/i,
+         use: ['style-loader', 'css-loader'],
+       },
+       {
+         test: /\.(png|svg|jpg|jpeg|gif)$/i,
+         type: 'asset/resource',
+       },
+       {
+         test: /\.(woff|woff2|eot|ttf|otf)$/i,
+         type: 'asset/resource',
+       },
+       {
+         test: /\.(csv|tsv)$/i,
+         use: ['csv-loader'],
+       },
+       {
+         test: /\.xml$/i,
+         use: ['xml-loader'],
+       },
++      {
++        test: /\.toml$/i,
++        type: 'json',
++        parser: {
++          parse: toml.parse,
++        },
++      },
++      {
++        test: /\.yaml$/i,
++        type: 'json',
++        parser: {
++          parse: yaml.parse,
++        },
++      },
++      {
++        test: /\.json5$/i,
++        type: 'json',
++        parser: {
++          parse: json5.parse,
++        },
++      },
+     ],
+   },
+ };
+```
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
+ import './style.css';
+ import Icon from './icon.png';
+ import Data from './data.xml';
+ import Notes from './data.csv';
++import toml from './data.toml';
++import yaml from './data.yaml';
++import json from './data.json5';
++
++console.log(toml.title); // output `TOML Example`
++console.log(toml.owner.name); // output `Tom Preston-Werner`
++
++console.log(yaml.title); // output `YAML Example`
++console.log(yaml.owner.name); // output `Tom Preston-Werner`
++
++console.log(json.title); // output `JSON5 Example`
++console.log(json.owner.name); // output `Tom Preston-Werner`
+
+ function component() {
+   const element = document.createElement('div');
+
+   // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+   element.classList.add('hello');
+
+   // Add the image to our existing div.
+   const myIcon = new Image();
+   myIcon.src = Icon;
+
+   element.appendChild(myIcon);
+
+   console.log(Data);
+   console.log(Notes);
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Re-run `npm run build` and open `dist/index.html`. You should see your imported data logged to the console.
+
+## Global Assets
+
+The best part of everything described above is that loading assets this way lets you group modules and assets in a more intuitive manner. Instead of keeping a single global `/assets` directory that holds everything, you can colocate assets with the code that uses them. For example, a structure like this can be helpful:
+
+```diff
+- ├── /assets
++ └── /components
++     └── /my-component
++         ├── index.jsx
++         ├── index.css
++         ├── icon.svg
++         └── img.png
+```
+
+This makes your code far more portable, since everything tightly coupled now lives together. If you want to use `/my-component` in another project, just copy or move it into that project's `/components` directory. As long as you've installed any _external dependencies_ and your _configuration defines the same loaders_, it should work.
+
+That said, if you prefer your old habits or you have assets shared across multiple components (views, templates, modules, and so on), you can still keep them in a base directory and use [aliasing](#TODO[/configuration/resolve/#resolvealias]) to make them easier to `import`.
+
+## Wrapping up
+
+The next guides won't use all the assets we've added here, so let's clean up to get ready for the next part, [Output Management](https://webpack.js.org/guides/output-management/):
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
+   ├── /dist
+   │   ├── bundle.js
+   │   └── index.html
+   ├── /src
+-  │   ├── data.csv
+-  │   ├── data.json5
+-  │   ├── data.toml
+-  │   ├── data.xml
+-  │   ├── data.yaml
+-  │   ├── icon.png
+-  │   ├── my-font.woff
+-  │   ├── my-font.woff2
+-  │   ├── style.css
+   │   └── index.js
+   └── /node_modules
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+-import toml from 'toml';
+-import yaml from 'yamljs';
+-import json5 from 'json5';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+-  module: {
+-    rules: [
+-      {
+-        test: /\.css$/i,
+-        use: ['style-loader', 'css-loader'],
+-      },
+-      {
+-        test: /\.(png|svg|jpg|jpeg|gif)$/i,
+-        type: 'asset/resource',
+-      },
+-      {
+-        test: /\.(woff|woff2|eot|ttf|otf)$/i,
+-        type: 'asset/resource',
+-      },
+-      {
+-        test: /\.(csv|tsv)$/i,
+-        use: ['csv-loader'],
+-      },
+-      {
+-        test: /\.xml$/i,
+-        use: ['xml-loader'],
+-      },
+-      {
+-        test: /\.toml$/i,
+-        type: 'json',
+-        parser: {
+-          parse: toml.parse,
+-        },
+-      },
+-      {
+-        test: /\.yaml$/i,
+-        type: 'json',
+-        parser: {
+-          parse: yaml.parse,
+-        },
+-      },
+-      {
+-        test: /\.json5$/i,
+-        type: 'json',
+-        parser: {
+-          parse: json5.parse,
+-        },
+-      },
+-    ],
+-  },
+ };
+```
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
+-import './style.css';
+-import Icon from './icon.png';
+-import Data from './data.xml';
+-import Notes from './data.csv';
+-import toml from './data.toml';
+-import yaml from './data.yaml';
+-import json from './data.json5';
+-
+-console.log(toml.title); // output `TOML Example`
+-console.log(toml.owner.name); // output `Tom Preston-Werner`
+-
+-console.log(yaml.title); // output `YAML Example`
+-console.log(yaml.owner.name); // output `Tom Preston-Werner`
+-
+-console.log(json.title); // output `JSON5 Example`
+-console.log(json.owner.name); // output `Tom Preston-Werner`
+
+ function component() {
+   const element = document.createElement('div');
+
+-  // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+-  element.classList.add('hello');
+-
+-  // Add the image to our existing div.
+-  const myIcon = new Image();
+-  myIcon.src = Icon;
+-
+-  element.appendChild(myIcon);
+-
+-  console.log(Data);
+-  console.log(Notes);
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Finally, remove the dependencies we added earlier:
+
+```bash
+npm uninstall css-loader csv-loader json5 style-loader toml xml-loader yamljs
+```
+
+## Next guide
+
+Let's move on to [Output Management](https://webpack.js.org/guides/output-management/).
+
+## Further Reading
+
+- [Loading Fonts](https://survivejs.com/webpack/loading/fonts/) on SurviveJS
diff --git a/pages/guides/core-workflows/asset-modules.md b/pages/guides/core-workflows/asset-modules.md
new file mode 100644
index 00000000..85dc55d5
--- /dev/null
+++ b/pages/guides/core-workflows/asset-modules.md
@@ -0,0 +1,566 @@
+---
+authors: smelukov,EugeneHlushko,chenxsan,anshumanv,spence-s,dkdk225,alexander-akait,GreenUpOu,avivkeller
+---
+
+# Asset Modules
+
+Asset modules let you work with asset files such as fonts and icons without setting up extra loaders.
+
+Before webpack 5, the common approach was to use:
+
+- [`raw-loader`](https://v4.webpack.js.org/loaders/raw-loader/) to import a file as a string.
+- [`url-loader`](https://v4.webpack.js.org/loaders/url-loader/) to inline a file into the bundle as a data URI.
+- [`file-loader`](https://v4.webpack.js.org/loaders/file-loader/) to emit a file into the output directory.
+
+Asset modules replace all of these loaders by introducing five new module types:
+
+- `asset/resource` emits a separate file and exports its URL. Previously achievable with `file-loader`.
+- `asset/inline` exports a data URI of the asset. Previously achievable with `url-loader`.
+- `asset/source` exports the source code of the asset. Previously achievable with `raw-loader`.
+- `asset/bytes` exports a [`Uint8Array`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array) view of the asset.
+- `asset` automatically chooses between exporting a data URI and emitting a separate file. Previously achievable with `url-loader` using an asset size limit.
+
+If you combine the old asset loaders (`file-loader`, `url-loader`, or `raw-loader`) with asset modules in webpack 5, you may want to prevent asset modules from processing the same assets again, since that would duplicate them. To do this, set the asset's module type to `'javascript/auto'`.
+
+```diff displayName="webpack.config.js"
+export default {
+  module: {
+   rules: [
+      {
+        test: /\.(png|jpg|gif)$/i,
+        use: [
+          {
+            loader: 'url-loader',
+            options: {
+              limit: 8192,
+            }
+          },
+        ],
++       type: 'javascript/auto'
+      },
+   ]
+  },
+}
+```
+
+To exclude assets that originate from `new URL` calls from the asset loaders, add `dependency: { not: ['url'] }` to the loader configuration.
+
+```diff displayName="webpack.config.js"
+export default {
+  module: {
+    rules: [
+      {
+        test: /\.(png|jpg|gif)$/i,
++       dependency: { not: ['url'] },
+        use: [
+          {
+            loader: 'url-loader',
+            options: {
+              limit: 8192,
+            },
+          },
+        ],
+      },
+    ],
+  }
+}
+```
+
+## Public path
+
+Under the hood, the `asset` type resolves URLs as `__webpack_public_path__ + import.meta` by default. As a result, setting `output.publicPath` in your configuration lets you override the URL from which the `asset` loads.
+
+### On-the-fly override
+
+If you set `__webpack_public_path__` in code, you need to run it as the very first code in your app, and you must not wrap it in a function, otherwise the `asset` loading logic will break. For example, you might have a file named `publicPath.js` with the following contents:
+
+```js
+__webpack_public_path__ = 'https://cdn.url.com';
+```
+
+Then, in your `webpack.config.js`, update the `entry` field to include it:
+
+```js
+export default {
+  entry: ['./publicPath.js', './App.js'],
+};
+```
+
+Alternatively, you can import it at the top of `App.js` without touching your webpack configuration. The only downside is that you must enforce import ordering yourself, which can conflict with some linting tools.
+
+```js
+import './publicPath.js';
+```
+
+## Resource type
+
+```diff displayName="webpack.config.js"
+import path from 'path';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist')
+  },
++ module: {
++   rules: [
++     {
++       test: /\.png/,
++       type: 'asset/resource',
++     },
++   ],
++ },
+};
+```
+
+```js displayName="src/index.js"
+import mainImage from './images/main.png';
+
+img.src = mainImage; // '/dist/151cfcfa1bd74779aadb.png'
+```
+
+All `.png` files will be emitted to the output directory and their paths will be injected into the bundles. You can also customize [`outputPath`](#TODO[/configuration/module/#rulegeneratoroutputpath]) and [`publicPath`](#TODO[/configuration/module/#rulegeneratorpublicpath]) for them.
+
+### Custom output filename
+
+By default, `asset/resource` modules are emitted into the output directory using the `[hash][ext][query]` filename template.
+
+You can change this template by setting [`output.assetModuleFilename`](#TODO[/configuration/output/#outputassetmodulefilename]) in your webpack configuration:
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
++   assetModuleFilename: 'images/[hash][ext][query]',
+  },
+  module: {
+    rules: [
+      {
+        test: /\.png/,
+        type: 'asset/resource',
+      },
+    ],
+  },
+};
+```
+
+Another reason to customize the output filename is to emit a certain kind of asset into a specific directory:
+
+```diff
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
++   assetModuleFilename: 'images/[hash][ext][query]',
+  },
+  module: {
+    rules: [
++     {
++       test: /\.html/,
++       type: 'asset/resource',
++       generator: {
++         filename: 'static/[hash][ext][query]',
++       },
++     },
+    ],
+  },
+};
+```
+
+With this configuration, all `.html` files will be emitted into a `static` directory inside the output directory.
+
+`Rule.generator.filename` behaves the same as [`output.assetModuleFilename`](#TODO[/configuration/output/#outputassetmodulefilename]) and works only with the `asset` and `asset/resource` module types.
+
+## Inlining assets
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+  module: {
+    rules: [
++     {
++       test: /\.svg/,
++       type: 'asset/inline',
++     },
+    ],
+  },
+};
+```
+
+```js displayName="src/index.js"
+import metroMap from './images/metro.svg';
+
+block.style.background = `url(${metroMap})`; // url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDo...vc3ZnPgo=)
+```
+
+All `.svg` files will be injected into the bundles as data URIs.
+
+### Custom data URI generator
+
+By default, the data URI that webpack emits represents the file contents encoded with the Base64 algorithm.
+
+If you want to use a custom encoding algorithm, you can provide a function to encode the file contents:
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
++ import svgToMiniDataURI from "mini-svg-data-uri";
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist')
+  },
+  module: {
+    rules: [
+      {
+        test: /\.svg/,
+        type: 'asset/inline',
++       generator: {
++         dataUrl: content => {
++           content = content.toString();
++           return svgToMiniDataURI(content);
++         },
++       },
+      },
+    ],
+  },
+};
+```
+
+Now all `.svg` files will be encoded with the `mini-svg-data-uri` package.
+
+## Source type
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+  module: {
+    rules: [
++     {
++       test: /\.txt/,
++       type: 'asset/source',
++     },
+    ],
+  },
+};
+```
+
+> [!TIP]
+> You don't need to add rules when using the `import text from './file.txt' with { type: "text" };` syntax.
+
+```text displayName="src/example.txt"
+Hello world
+```
+
+```js displayName="src/index.js"
+import exampleText from './example.txt';
+
+block.textContent = exampleText; // 'Hello world';
+```
+
+Alternative usage:
+
+```js displayName="src/index.js"
+import exampleText from './example.txt' with { type: 'text' };
+
+block.textContent = exampleText; // 'Hello world';
+```
+
+All `.txt` files will be injected into the bundles as UTF-8 strings.
+
+## URL assets
+
+When you use `new URL('./path/to/asset', import.meta.url)`, webpack creates an asset module too.
+
+> [!TIP]
+> You don't need to add rules when using the `const file = new URL('./file.ext', import.meta.url);` syntax.
+
+```js displayName="src/index.js"
+const logo = new URL('./logo.svg', import.meta.url);
+```
+
+Depending on the [`target`](#TODO[/configuration/target/]) in your configuration, webpack compiles the code above into different output:
+
+```js
+// target: web
+new URL(
+  `${__webpack_public_path__}logo.svg`,
+  document.baseURI || self.location.href
+);
+
+// target: webworker
+new URL(`${__webpack_public_path__}logo.svg`, self.location);
+
+// target: node, node-webkit, nwjs, electron-main, electron-renderer, electron-preload, async-node
+new URL(
+  `${__webpack_public_path__}logo.svg`,
+  require('node:url').pathToFileUrl(__filename)
+);
+```
+
+```js
+// any targets when ECMAScript modules output is enabled
+new URL(`${__webpack_public_path__}logo.svg`, import.meta.url);
+```
+
+As of webpack 5.38.0, [data URLs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs) are supported in `new URL()` as well:
+
+```js displayName="src/index.js"
+const url = new URL('data:,', import.meta.url);
+console.log(url.href === 'data:,');
+console.log(url.protocol === 'data:');
+console.log(url.pathname === ',');
+```
+
+## Asset type
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist')
+  },
+  module: {
+    rules: [
++     {
++       test: /\.txt/,
++       type: 'asset',
++     },
+    ],
+  },
+};
+```
+
+Now webpack automatically chooses between `resource` and `inline` based on a default condition: a file smaller than 8kb is treated as an `inline` module type, and larger files use the `resource` module type.
+
+You can change this condition by setting the [`Rule.parser.dataUrlCondition.maxSize`](#TODO[/configuration/module/#ruleparserdataurlcondition]) option at the module rule level of your webpack configuration:
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+  module: {
+    rules: [
+      {
+        test: /\.txt/,
+        type: 'asset',
++       parser: {
++         dataUrlCondition: {
++           maxSize: 4 * 1024, // 4kb
++         },
++       },
+      },
+    ],
+  },
+};
+```
+
+You can also [specify a function](#TODO[/configuration/module/#ruleparserdataurlcondition]) to decide whether to inline a module.
+
+## Bytes type
+
+```diff displayName="webpack.config.js"
+import path from "node:path";
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+  module: {
+    rules: [
++     {
++       test: /\.txt/,
++       type: 'asset/bytes',
++     },
+    ],
+  },
+};
+```
+
+> [!TIP]
+> You don't need to add rules when using the `import data from './file.ext' with { type: "bytes" };` syntax.
+
+```text displayName="src/example.txt"
+Hello world
+```
+
+```js displayName="src/index.js"
+import exampleText from './example.txt';
+
+const decoder = new TextDecoder('utf-8');
+const textString = decoder.decode(exampleText);
+
+block.textContent = textString; // 'Hello world';
+```
+
+Alternative usage:
+
+```js displayName="src/index.js"
+import exampleText from './example.txt' with { type: 'bytes' };
+
+const decoder = new TextDecoder('utf-8');
+const textString = decoder.decode(exampleText);
+
+block.textContent = textString; // 'Hello world';
+```
+
+All `.txt` files will be injected into the bundles as raw bytes (`Uint8Array`), without any text encoding or transformation.
+
+## Replacing inline loader syntax
+
+Before asset modules and webpack 5, it was possible to use [inline syntax](https://webpack.js.org/concepts/loaders/#inline) with the legacy loaders mentioned above.
+
+It is now recommended to remove all inline loader syntax and use a `resourceQuery` condition to reproduce the behavior of the inline syntax.
+
+For example, to replace `raw-loader` with the `asset/source` type:
+
+```diff
+- import myModule from 'raw-loader!my-module';
++ import myModule from 'my-module?raw';
+```
+
+And in the webpack configuration:
+
+```diff
+module: {
+    rules: [
+    // ...
++     {
++       resourceQuery: /raw/,
++       type: 'asset/source',
++     }
+    ]
+  },
+```
+
+If you want to exclude raw assets from being processed by other loaders, use a negative condition:
+
+```diff
+module: {
+    rules: [
+    // ...
++     {
++       test: /\.m?js$/,
++       resourceQuery: { not: [/raw/] },
++       use: [ ... ]
++     },
+      {
+        resourceQuery: /raw/,
+        type: 'asset/source',
+      }
+    ]
+  },
+```
+
+Alternatively, use a `oneOf` list of rules, where only the first matching rule is applied:
+
+```diff
+module: {
+    rules: [
+    // ...
++     { oneOf: [
+        {
+          resourceQuery: /raw/,
+          type: 'asset/source',
+        },
++       {
++         test: /\.m?js$/,
++         use: [ ... ]
++       },
++     ] }
+    ]
+  },
+```
+
+## Disable emitting assets
+
+For use cases such as server-side rendering, you might want to disable emitting assets. This is possible with the [`emit`](#TODO[/configuration/module/#rulegeneratoremit]) option under `Rule.generator`:
+
+```js
+export default {
+  // …
+  module: {
+    rules: [
+      {
+        test: /\.png$/i,
+        type: 'asset/resource',
+        generator: {
+          emit: false,
+        },
+      },
+    ],
+  },
+};
+```
+
+## Further reading
+
+- [webpack 5 - Asset Modules](https://dev.to/smelukov/webpack-5-asset-modules-2o3h)
diff --git a/pages/guides/core-workflows/development/hot-module-replacement.md b/pages/guides/core-workflows/development/hot-module-replacement.md
new file mode 100644
index 00000000..9b1053e2
--- /dev/null
+++ b/pages/guides/core-workflows/development/hot-module-replacement.md
@@ -0,0 +1,376 @@
+---
+authors: jmreidy,jhnns,sararubin,rohannair,joshsantos,drpicox,skipjack,sbaidon,gdi2290,bdwain,caryli,xgirma,EugeneHlushko,AnayaDesign,aviyacohen,dhruvdutt,wizardofhogwarts,aholzner,snitin315,Brennvo,avivkeller
+---
+
+# Hot Module Replacement
+
+> [!TIP]
+> This guide builds on the code examples found in the [Development](#TODO[/guides/development]) guide.
+
+Hot Module Replacement (HMR) is one of the most useful features webpack offers. It lets all kinds of modules update at runtime without a full page refresh. This page focuses on **implementation**, while the [concepts page](#TODO[/concepts/hot-module-replacement]) covers how HMR works and why it's useful.
+
+> [!WARNING]
+> HMR is not intended for use in production; it should only be used during development. See the [building for production guide](#TODO[/guides/production]) for more information.
+
+## Enabling HMR
+
+This feature is great for productivity. All we need to do is update our [webpack-dev-server](https://github.com/webpack/webpack-dev-server) configuration and use webpack's built-in HMR plugin. We'll also remove the entry point for `print.js`, since it will now be consumed by the `index.js` module.
+
+Since `webpack-dev-server` v4.0.0, Hot Module Replacement is enabled by default.
+
+> [!TIP]
+> If you took the route of using `webpack-dev-middleware` instead of `webpack-dev-server`, use the [`webpack-hot-middleware`](https://github.com/webpack/webpack-hot-middleware) package to enable HMR on your custom server or application.
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+  import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: {
+       app: './src/index.js',
+-      print: './src/print.js',
+    },
+    devtool: 'inline-source-map',
+    devServer: {
+      static: './dist',
++     hot: true,
+    },
+    plugins: [
+      new HtmlWebpackPlugin({
+        title: 'Hot Module Replacement',
+      }),
+    ],
+    output: {
+      filename: '[name].bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+      clean: true,
+    },
+  };
+```
+
+You can also provide manual entry points for HMR:
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+  import HtmlWebpackPlugin from 'html-webpack-plugin';
++ import webpack from 'webpack';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: {
+       app: './src/index.js',
+-      print: './src/print.js',
++      // Runtime code for hot module replacement
++      hot: 'webpack/hot/dev-server.js',
++      // Dev server client for web socket transport, hot and live reload logic
++      client: 'webpack-dev-server/client/index.js?hot=true&live-reload=true',
+    },
+    devtool: 'inline-source-map',
+    devServer: {
+      static: './dist',
++     // Dev server client for web socket transport, hot and live reload logic
++     hot: false,
++     client: false,
+    },
+    plugins: [
+      new HtmlWebpackPlugin({
+        title: 'Hot Module Replacement',
+      }),
++     // Plugin for hot module replacement
++     new webpack.HotModuleReplacementPlugin(),
+    ],
+    output: {
+      filename: '[name].bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+      clean: true,
+    },
+  };
+```
+
+> [!TIP]
+> You can use the CLI to modify the [webpack-dev-server](https://github.com/webpack/webpack-dev-server) configuration with the following command: `webpack serve --hot-only`.
+
+Now let's update the `index.js` file so that when a change inside `print.js` is detected, we tell webpack to accept the updated module.
+
+```diff displayName="index.js"
+  import _ from 'lodash';
+  import printMe from './print.js';
+
+  function component() {
+    const element = document.createElement('div');
+    const btn = document.createElement('button');
+
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+    btn.innerHTML = 'Click me and check the console!';
+    btn.onclick = printMe;
+
+    element.appendChild(btn);
+
+    return element;
+  }
+
+  document.body.appendChild(component());
++
++ if (module.hot) {
++   module.hot.accept('./print.js', function() {
++     console.log('Accepting the updated printMe module!');
++     printMe();
++   })
++ }
+```
+
+Start changing the `console.log` statement in `print.js`, and you should see the following output in the browser console (don't worry about that `button.onclick = printMe` output for now; we'll update that part later).
+
+```diff displayName="print.js"
+  export default function printMe() {
+-   console.log('I get called from print.js!');
++   console.log('Updating print.js...');
+  }
+```
+
+```diff displayName="console"
+[HMR] Waiting for update signal from WDS...
+main.js:4395 [WDS] Hot Module Replacement enabled.
++ 2main.js:4395 [WDS] App updated. Recompiling...
++ main.js:4395 [WDS] App hot update...
++ main.js:4330 [HMR] Checking for updates on the server...
++ main.js:10024 Accepting the updated printMe module!
++ 0.4b8ee77….hot-update.js:10 Updating print.js...
++ main.js:4330 [HMR] Updated modules:
++ main.js:4330 [HMR]  - 20
+```
+
+## Via the Node.js API
+
+When using webpack-dev-server with the Node.js API, don't put the dev server options on the webpack configuration object. Instead, pass them as a second parameter on creation. For example:
+
+`new WebpackDevServer(options, compiler)`
+
+To enable HMR, you also need to modify your webpack configuration object to include the HMR entry points. Here's a small example of how that might look:
+
+```js displayName="dev-server.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import HtmlWebpackPlugin from 'html-webpack-plugin';
+import webpack from 'webpack';
+import WebpackDevServer from 'webpack-dev-server';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+const config = {
+  mode: 'development',
+  entry: [
+    // Runtime code for hot module replacement
+    'webpack/hot/dev-server.js',
+    // Dev server client for web socket transport, hot and live reload logic
+    'webpack-dev-server/client/index.js?hot=true&live-reload=true',
+    // Your entry
+    './src/index.js',
+  ],
+  devtool: 'inline-source-map',
+  plugins: [
+    // Plugin for hot module replacement
+    new webpack.HotModuleReplacementPlugin(),
+    new HtmlWebpackPlugin({
+      title: 'Hot Module Replacement',
+    }),
+  ],
+  output: {
+    filename: '[name].bundle.js',
+    path: path.resolve(__dirname, 'dist'),
+    clean: true,
+  },
+};
+const compiler = webpack(config);
+
+// `hot` and `client` options are disabled because we added them manually
+const server = new WebpackDevServer({ hot: false, client: false }, compiler);
+
+try {
+  await server.start();
+  console.log('dev server is running');
+} catch (err) {
+  throw new Error(`Failed to start dev server: ${err.message}`, { cause: err });
+}
+```
+
+See the [full documentation of the `webpack-dev-server` Node.js API](#TODO[/api/webpack-dev-server/]).
+
+> [!TIP]
+> If you're [using `webpack-dev-middleware`](#TODO[/guides/development/#using-webpack-dev-middleware]), check out the [`webpack-hot-middleware`](https://github.com/webpack/webpack-hot-middleware) package to enable HMR on your custom dev server.
+
+## Gotchas
+
+Hot Module Replacement can be tricky. To show this, let's return to our working example. If you click the button on the example page, you'll notice the console prints the old `printMe` function.
+
+This happens because the button's `onclick` event handler is still bound to the original `printMe` function.
+
+To make this work with HMR, we need to update that binding to the new `printMe` function using `module.hot.accept`:
+
+```diff displayName="index.js"
+  import _ from 'lodash';
+  import printMe from './print.js';
+
+  function component() {
+    const element = document.createElement('div');
+    const btn = document.createElement('button');
+
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+    btn.innerHTML = 'Click me and check the console!';
+    btn.onclick = printMe;  // onclick event is bound to the original printMe function
+
+    element.appendChild(btn);
+
+    return element;
+  }
+
+- document.body.appendChild(component());
++ let element = component(); // Store the element to re-render on print.js changes
++ document.body.appendChild(element);
+
+  if (module.hot) {
+    module.hot.accept('./print.js', function() {
+      console.log('Accepting the updated printMe module!');
+-     printMe();
++     document.body.removeChild(element);
++     element = component(); // Re-render the "component" to update the click handler
++     document.body.appendChild(element);
+    })
+  }
+```
+
+This is only one example, but many others can easily trip people up. Fortunately, there are a lot of loaders out there (some mentioned below) that make hot module replacement much easier.
+
+## HMR with stylesheets
+
+Hot Module Replacement with CSS is actually fairly straightforward with the help of `style-loader`. Behind the scenes, this loader uses `module.hot.accept` to patch `<style>` tags when CSS dependencies are updated.
+
+First, let's install both loaders with the following command:
+
+```bash
+npm install --save-dev style-loader css-loader
+```
+
+Now let's update the configuration file to make use of the loader.
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+  import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: {
+      app: './src/index.js',
+    },
+    devtool: 'inline-source-map',
+    devServer: {
+      static: './dist',
+      hot: true,
+    },
++   module: {
++     rules: [
++       {
++         test: /\.css$/,
++         use: ['style-loader', 'css-loader'],
++       },
++     ],
++   },
+    plugins: [
+      new HtmlWebpackPlugin({
+        title: 'Hot Module Replacement',
+      }),
+    ],
+    output: {
+      filename: '[name].bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+      clean: true,
+    },
+  };
+```
+
+Hot loading stylesheets is done by importing them into a module:
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── webpack.config.js
+  ├── /dist
+  │   └── bundle.js
+  └── /src
+      ├── index.js
+      ├── print.js
++     └── styles.css
+```
+
+```css displayName="styles.css"
+body {
+  background: blue;
+}
+```
+
+```diff displayName="index.js"
+  import _ from 'lodash';
+  import printMe from './print.js';
++ import './styles.css';
+
+  function component() {
+    const element = document.createElement('div');
+    const btn = document.createElement('button');
+
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+    btn.innerHTML = 'Click me and check the console!';
+    btn.onclick = printMe;  // onclick event is bound to the original printMe function
+
+    element.appendChild(btn);
+
+    return element;
+  }
+
+  let element = component();
+  document.body.appendChild(element);
+
+  if (module.hot) {
+    module.hot.accept('./print.js', function() {
+      console.log('Accepting the updated printMe module!');
+      document.body.removeChild(element);
+      element = component(); // Re-render the "component" to update the click handler
+      document.body.appendChild(element);
+    })
+  }
+```
+
+Change the style on `body` to `background: red;`, and you should immediately see the page's background color change without a full refresh.
+
+```diff displayName="styles.css"
+  body {
+-   background: blue;
++   background: red;
+  }
+```
+
+## Other code and frameworks
+
+There are many other loaders and examples in the community to make HMR interact smoothly with a variety of frameworks and libraries:
+
+- [React Hot Loader](https://github.com/gaearon/react-hot-loader): Tweak React components in real time.
+- [Vue Loader](https://github.com/vuejs/vue-loader): Supports HMR for Vue components out of the box.
+- [Elm Hot webpack Loader](https://github.com/klazuka/elm-hot-webpack-loader): Supports HMR for the Elm programming language.
+- [Angular HMR](https://angular.io/cli/serve): No loader necessary! HMR support is built into the Angular CLI; add the `--hmr` flag to your `ng serve` command.
+- [Svelte Loader](https://github.com/sveltejs/svelte-loader): Supports HMR for Svelte components out of the box.
+
+> [!TIP]
+> If you know of any other loaders or plugins that help with or enhance HMR, please submit a pull request to add them to this list!
diff --git a/pages/guides/core-workflows/development/index.md b/pages/guides/core-workflows/development/index.md
new file mode 100644
index 00000000..9f266ba8
--- /dev/null
+++ b/pages/guides/core-workflows/development/index.md
@@ -0,0 +1,422 @@
+---
+authors: SpaceK33z,rafde,fvgs,TheDutchCoder,WojciechKo,Calinou,GAumala,EugeneHlushko,byzyk,trivikr,aholzner,chenxsan,maxloh,snitin315,f3ndot,Brennvo,avivkeller
+---
+
+# Development
+
+> [!TIP]
+> This guide builds on the code examples from the [Output Management](#TODO[/guides/output-management]) guide.
+
+If you've worked through the previous guides, you should now have a solid grasp of webpack's fundamentals. Before moving on, let's set up a development environment that makes day-to-day work a little smoother.
+
+> [!WARNING]
+> The tools described in this guide are intended **only for development**. Do **not** use them in production.
+
+Start by setting [`mode` to `'development'`](#TODO[/configuration/mode/#mode-development]) and `title` to `'Development'`.
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
++  mode: 'development',
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
+   plugins: [
+     new HtmlWebpackPlugin({
+-      title: 'Output Management',
++      title: 'Development',
+     }),
+   ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
+ };
+```
+
+## Using source maps
+
+When webpack bundles your source code, tracing errors and warnings back to their original location can be difficult. For example, if you bundle three source files (`a.js`, `b.js`, and `c.js`) into a single `bundle.js` and one of them throws an error, the stack trace points to `bundle.js`. That's rarely helpful, since you usually want to know exactly which source file the error came from.
+
+To make errors and warnings easier to track down, JavaScript supports [source maps](http://blog.teamtreehouse.com/introduction-source-maps), which map your compiled code back to the original source. If an error originates in `b.js`, the source map will tell you precisely that.
+
+webpack offers many [different options](#TODO[/configuration/devtool]) for source maps. It's worth reviewing them so you can pick the one that fits your needs.
+
+For this guide, we'll use the `inline-source-map` option. It's well suited for demonstration, though not for production:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
++  devtool: 'inline-source-map',
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Development',
+     }),
+   ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
+ };
+```
+
+Now let's give ourselves something to debug by introducing an error in `print.js`:
+
+```diff displayName="src/print.js"
+ export default function printMe() {
+-  console.log('I get called from print.js!');
++  cosnole.log('I get called from print.js!');
+ }
+```
+
+Run `npm run build`, and it should compile to something like this:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset index.bundle.js 1.38 MiB [emitted] (name: index)
+asset print.bundle.js 6.25 KiB [emitted] (name: print)
+asset index.html 272 bytes [emitted]
+runtime modules 1.9 KiB 9 modules
+cacheable modules 530 KiB
+  ./src/index.js 406 bytes [built] [code generated]
+  ./src/print.js 83 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 706 ms
+```
+
+Now open the resulting `index.html` in your browser, click the button, and check the console where the error appears. It should read something like:
+
+```bash
+Uncaught ReferenceError: cosnole is not defined
+   at HTMLButtonElement.printMe (print.js:2)
+```
+
+Notice that the error references the file (`print.js`) and the line number (2) where it occurred. That's exactly what we want, since it tells us precisely where to look to fix the problem.
+
+## Choosing a development tool
+
+> [!WARNING]
+> Some text editors have a "safe write" feature that can interfere with the tools below. See [Adjusting your text editor](#adjusting-your-text-editor) for a fix.
+
+Manually running `npm run build` every time you want to compile quickly becomes tedious.
+
+webpack provides several options that recompile your code automatically whenever it changes:
+
+1. webpack's [Watch Mode](#TODO[/configuration/watch/#watch])
+2. [webpack-dev-server](https://github.com/webpack/webpack-dev-server)
+3. [webpack-dev-middleware](https://github.com/webpack/webpack-dev-middleware)
+
+In most cases you'll want `webpack-dev-server`, but let's walk through all three.
+
+### Using Watch Mode
+
+You can tell webpack to "watch" every file in your dependency graph for changes. When one of them is updated, your code is recompiled automatically, so you don't have to run a full build by hand.
+
+Let's add an npm script that starts webpack's Watch Mode:
+
+```diff displayName="package.json"
+ {
+   "name": "webpack-demo",
+   "version": "1.0.0",
+   "description": "",
+   "private": true,
+   "scripts": {
+     "test": "echo \"Error: no test specified\" && exit 1",
++    "watch": "webpack --watch",
+     "build": "webpack"
+   },
+   "keywords": [],
+   "author": "",
+   "license": "ISC",
+   "devDependencies": {
+     "html-webpack-plugin": "^5.6.6",
+     "webpack": "^5.105.0",
+     "webpack-cli": "^7.0.0"
+   },
+   "dependencies": {
+     "lodash": "^4.17.21"
+   }
+ }
+```
+
+Now run `npm run watch` from the command line and watch webpack compile your code. Notice that it doesn't return to the prompt, because the script keeps watching your files.
+
+While webpack is watching, let's remove the error we introduced earlier:
+
+```diff displayName="src/print.js"
+ export default function printMe() {
+-  cosnole.log('I get called from print.js!');
++  console.log('I get called from print.js!');
+ }
+```
+
+Save the file and check the terminal. You should see webpack automatically recompile the changed module.
+
+The one drawback is that you still have to refresh the browser to see the changes. It would be far nicer if that happened automatically too, so let's try `webpack-dev-server`, which does exactly that.
+
+### Using webpack-dev-server
+
+`webpack-dev-server` gives you a basic web server with live reloading. Let's set it up:
+
+```bash
+npm install --save-dev webpack-dev-server
+```
+
+Update your configuration file to tell the dev server where to find files:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
+   devtool: 'inline-source-map',
++  devServer: {
++    static: './dist',
++  },
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Development',
+     }),
+   ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
++  optimization: {
++    runtimeChunk: 'single',
++  },
+ };
+```
+
+This tells `webpack-dev-server` to serve the files from the `dist` directory on `localhost:8080`.
+
+> [!TIP]
+> `optimization.runtimeChunk: 'single'` was added because this example uses more than one entry point on a single HTML page. Without it, we'd run into the problem described [here](https://bundlers.tooling.report/code-splitting/multi-entry/). See the [Code Splitting](#TODO[/guides/code-splitting/]) chapter for more details.
+
+> [!TIP]
+> `webpack-dev-server` serves bundled files from the directory defined in [`output.path`](#TODO[/configuration/output/#outputpath]); that is, files are available under `http://[devServer.host]:[devServer.port]/[output.publicPath]/[output.filename]`.
+
+> [!WARNING]
+> `webpack-dev-server` doesn't write any output files after compiling. Instead, it keeps the bundles in memory and serves them as if they were real files mounted at the server's root path. If your page expects the bundles at a different path, change it with the [`devMiddleware.publicPath`](#TODO[/configuration/dev-server/#devserverdevmiddleware]) option in the dev server's configuration.
+
+Let's also add a script to make running the dev server easier:
+
+```diff displayName="package.json"
+ {
+   "name": "webpack-demo",
+   "version": "1.0.0",
+   "description": "",
+   "private": true,
+   "scripts": {
+     "test": "echo \"Error: no test specified\" && exit 1",
+     "watch": "webpack --watch",
++    "start": "webpack serve --open",
+     "build": "webpack"
+   },
+   "keywords": [],
+   "author": "",
+   "license": "ISC",
+   "devDependencies": {
+     "html-webpack-plugin": "^5.6.6",
+     "webpack": "^5.105.0",
+     "webpack-cli": "^7.0.0",
+     "webpack-dev-server": "^5.2.3"
+   },
+   "dependencies": {
+     "lodash": "^4.17.21"
+   }
+ }
+```
+
+Now run `npm start` from the command line, and your browser will open the page automatically. Change and save any source file, and the server will reload once the code has recompiled. Give it a try!
+
+`webpack-dev-server` offers many configurable options. Head over to the [documentation](#TODO[/configuration/dev-server]) to learn more.
+
+> [!TIP]
+> Now that your server is up and running, you might want to give [Hot Module Replacement](#TODO[/guides/hot-module-replacement]) a try!
+
+### Using webpack-dev-middleware
+
+`webpack-dev-middleware` is a wrapper that emits files processed by webpack to a server. It's used internally by `webpack-dev-server`, but it's also available as a standalone package for more custom setups. Let's look at an example that pairs `webpack-dev-middleware` with an Express server.
+
+First, install `express` and `webpack-dev-middleware`:
+
+```bash
+npm install --save-dev express webpack-dev-middleware
+```
+
+Next, adjust the webpack configuration so the middleware works correctly:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
+   devtool: 'inline-source-map',
+   devServer: {
+     static: './dist',
+   },
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Development',
+     }),
+   ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
++    publicPath: '/',
+   },
+ };
+```
+
+The `publicPath` will also be used in our server script to ensure files are served correctly on `http://localhost:3000`. We'll specify the port shortly. Next, set up the custom Express server:
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
+   ├── webpack.config.js
++  ├── server.js
+   ├── /dist
+   ├── /src
+   │   ├── index.js
+   │   └── print.js
+   └── /node_modules
+```
+
+```js displayName="server.js"
+import express from 'express';
+import webpack from 'webpack';
+import webpackDevMiddleware from 'webpack-dev-middleware';
+import config from './webpack.config.js';
+
+const app = express();
+const compiler = webpack(config);
+
+// Tell express to use the webpack-dev-middleware and use the webpack.config.js
+// configuration file as a base.
+app.use(
+  webpackDevMiddleware(compiler, {
+    publicPath: config.output.publicPath,
+  })
+);
+
+// Serve the files on port 3000.
+app.listen(3000, () => {
+  console.log('Example app listening on port 3000!\n');
+});
+```
+
+Now add an npm script to make running the server a little easier:
+
+```diff displayName="package.json"
+ {
+   "name": "webpack-demo",
+   "version": "1.0.0",
+   "description": "",
+   "private": true,
+   "scripts": {
+     "test": "echo \"Error: no test specified\" && exit 1",
+     "watch": "webpack --watch",
+     "start": "webpack serve --open",
++    "server": "node server.js",
+     "build": "webpack"
+   },
+   "keywords": [],
+   "author": "",
+   "license": "ISC",
+   "devDependencies": {
+     "express": "^5.2.1",
+     "html-webpack-plugin": "^5.6.6",
+     "webpack": "^5.105.0",
+     "webpack-cli": "^7.0.0",
+     "webpack-dev-middleware": "^8.0.3",
+     "webpack-dev-server": "^5.2.3"
+   },
+   "dependencies": {
+     "lodash": "^4.17.21"
+   }
+ }
+```
+
+Now run `npm run server` in your terminal. The output should look similar to this:
+
+```bash
+Example app listening on port 3000!
+...
+<i> [webpack-dev-middleware] asset index.bundle.js 1.38 MiB [emitted] (name: index)
+<i> asset print.bundle.js 6.25 KiB [emitted] (name: print)
+<i> asset index.html 274 bytes [emitted]
+<i> runtime modules 1.9 KiB 9 modules
+<i> cacheable modules 530 KiB
+<i>   ./src/index.js 406 bytes [built] [code generated]
+<i>   ./src/print.js 83 bytes [built] [code generated]
+<i>   ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+<i> webpack 5.x.x compiled successfully in 709 ms
+<i> [webpack-dev-middleware] Compiled successfully.
+<i> [webpack-dev-middleware] Compiling...
+<i> [webpack-dev-middleware] assets by status 1.38 MiB [cached] 2 assets
+<i> cached modules 530 KiB (javascript) 1.9 KiB (runtime) [cached] 12 modules
+<i> webpack 5.x.x compiled successfully in 19 ms
+<i> [webpack-dev-middleware] Compiled successfully.
+```
+
+Now open your browser at `http://localhost:3000`. You should see your webpack app up and running!
+
+> [!TIP]
+> If you'd like to learn more about how Hot Module Replacement works, we recommend reading the [Hot Module Replacement](#TODO[/guides/hot-module-replacement/]) guide.
+
+## Adjusting your text editor
+
+When relying on automatic compilation, you may hit issues when saving files. Some editors have a "safe write" feature that can interfere with recompilation.
+
+To disable it in a few common editors:
+
+- **Sublime Text 3**: Add `atomic_save: 'false'` to your user preferences.
+- **JetBrains IDEs (e.g. WebStorm)**: Uncheck "Use safe write" under `Preferences > Appearance & Behavior > System Settings`.
+- **Vim**: Add `:set backupcopy=yes` to your settings.
+
+## Conclusion
+
+Now that you know how to compile your code automatically and run a development server, you can move on to the next guide, which covers [Code Splitting](#TODO[/guides/code-splitting/]).
diff --git a/pages/guides/core-workflows/development/vagrant.md b/pages/guides/core-workflows/development/vagrant.md
new file mode 100644
index 00000000..99128559
--- /dev/null
+++ b/pages/guides/core-workflows/development/vagrant.md
@@ -0,0 +1,107 @@
+---
+authors: SpaceK33z,chrisVillanueva,byzyk,wizardofhogwarts,Brennvo,avivkeller
+---
+
+# Development with Vagrant
+
+If you have a more advanced project that uses [Vagrant](https://www.vagrantup.com/) to run your development environment inside a virtual machine, you'll usually want to run webpack inside that VM as well. This guide walks through configuring the project, serving it, and optionally proxying it through nginx.
+
+## Configuring the project
+
+First, make sure your `Vagrantfile` assigns a static IP:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network :private_network, ip: "10.10.10.61"
+end
+```
+
+Next, install `webpack`, `webpack-cli`, `@webpack-cli/serve`, and `webpack-dev-server` in your project:
+
+```bash
+npm install --save-dev webpack webpack-cli @webpack-cli/serve webpack-dev-server
+```
+
+You'll also need a `webpack.config.js` file. If you don't have one yet, this minimal example is enough to get started:
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  context: __dirname,
+  entry: './app.js',
+};
+```
+
+Then create an `index.html` file whose script tag points to your bundle. When `output.filename` isn't set in the config, the bundle defaults to `bundle.js`:
+
+```html displayName="index.html"
+<!DOCTYPE html>
+<html>
+  <head>
+    <script src="/bundle.js" charset="utf-8"></script>
+  </head>
+  <body>
+    <h2>Hey!</h2>
+  </body>
+</html>
+```
+
+Remember to create an `app.js` file too, since that's the entry point referenced in the config.
+
+## Running the server
+
+Now start the server:
+
+```bash
+webpack serve --host 0.0.0.0 --client-web-socket-url ws://10.10.10.61:8080/ws --watch-options-poll
+```
+
+By default the server is only reachable from localhost. Since we want to reach it from the host machine, we set `--host` to `0.0.0.0` to allow that.
+
+`webpack-dev-server` injects a script into your bundle that opens a WebSocket connection and triggers a reload whenever one of your files changes. The `--client-web-socket-url` flag tells that script where to find the WebSocket. Because the server listens on port `8080` by default, we specify that here as well.
+
+`--watch-options-poll` ensures that webpack can detect file changes. By default, webpack relies on events emitted by the filesystem, but VirtualBox has many problems delivering those events.
+
+The server should now be available at `http://10.10.10.61:8080`. Making a change in `app.js` should trigger a live reload.
+
+## Advanced usage with nginx
+
+To more closely mirror a production environment, you can proxy `webpack-dev-server` through nginx.
+
+Add the following to your nginx configuration file:
+
+```nginx
+server {
+  location / {
+    proxy_pass http://127.0.0.1:8080;
+    proxy_http_version 1.1;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection "upgrade";
+    error_page 502 @start-webpack-dev-server;
+  }
+
+  location @start-webpack-dev-server {
+    default_type text/plain;
+    return 502 "Please start the webpack-dev-server first.";
+  }
+}
+```
+
+The `proxy_set_header` lines are important, as they allow the WebSocket connection to work correctly.
+
+You can then change the command that starts `webpack-dev-server` to:
+
+```bash
+webpack serve --client-web-socket-url ws://10.10.10.61:8080/ws --watch-options-poll
+```
+
+This keeps the server accessible only on `127.0.0.1`, which is fine because nginx is responsible for exposing it to your host machine.
+
+## Conclusion
+
+We gave the Vagrant box a static IP, then made `webpack-dev-server` publicly accessible so it can be reached from a browser. Along the way we worked around a common issue where VirtualBox doesn't emit filesystem events, which would otherwise prevent the server from reloading on file changes.
diff --git a/pages/guides/core-workflows/environment-variables.md b/pages/guides/core-workflows/environment-variables.md
new file mode 100644
index 00000000..e9c94a6a
--- /dev/null
+++ b/pages/guides/core-workflows/environment-variables.md
@@ -0,0 +1,46 @@
+---
+authors: simon04,grisanu,tbroadley,legalcodes,byzyk,jceipek,snitin315,Brennvo,avivkeller
+---
+
+# Environment Variables
+
+To distinguish between [development](#TODO[/guides/development]) and [production builds](#TODO[/guides/production]) in your `webpack.config.js`, you can use environment variables.
+
+> [!TIP]
+> webpack's environment variables are different from the [environment variables](https://en.wikipedia.org/wiki/Environment_variable) of operating system shells such as `bash` and `CMD.exe`.
+
+The webpack command line [environment option](#TODO[/api/cli/#environment-options]) `--env` lets you pass in as many environment variables as you like, and they're then made available in your `webpack.config.js`. For example, `--env production` or `--env goal=local`.
+
+```bash
+npx webpack --env goal=local --env production --progress
+```
+
+> [!TIP]
+> Setting an `env` variable without an assignment, such as `--env production`, sets `env.production` to `true` by default. Other syntaxes are also available. See the [webpack CLI](#TODO[/api/cli/#environment-options]) documentation for more information.
+
+You'll need to make one change to your webpack config. Typically, `export default` points directly to the configuration object. To use the `env` variable, you must make `export default` a function instead:
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default env => {
+  // Use env.<YOUR VARIABLE> here:
+  console.log('Goal:', env.goal); // 'local'
+  console.log('Production:', env.production); // true
+
+  return {
+    entry: './src/index.js',
+    output: {
+      filename: 'bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+    },
+  };
+};
+```
+
+> [!TIP]
+> The webpack CLI provides some [built-in environment variables](#TODO[/api/cli/#cli-environment-variables]) that you can access inside a webpack configuration.
diff --git a/pages/guides/core-workflows/output-management.md b/pages/guides/core-workflows/output-management.md
new file mode 100644
index 00000000..0cf4ca03
--- /dev/null
+++ b/pages/guides/core-workflows/output-management.md
@@ -0,0 +1,225 @@
+---
+authors: skipjack,TheDutchCoder,sudarsangp,JGJP,EugeneHlushko,AnayaDesign,chenxsan,snitin315,Brennvo,avivkeller
+---
+
+# Output Management
+
+> [!TIP]
+> This guide builds on the code examples from the [Asset Management](#TODO[/guides/asset-management]) guide.
+
+So far we've manually listed every asset in our `index.html` file. As an application grows, and once you start [using hashes in filenames](#TODO[/guides/caching]) and outputting [multiple bundles](#TODO[/guides/code-splitting]), maintaining `index.html` by hand becomes difficult. Fortunately, a few plugins make this much easier to manage.
+
+## Preparation
+
+First, let's adjust the project a little:
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
++ │   ├── print.js
+  └── /node_modules
+```
+
+Add some logic to `src/print.js`:
+
+```js displayName="src/print.js"
+export default function printMe() {
+  console.log('I get called from print.js!');
+}
+```
+
+Then use that function in `src/index.js`:
+
+```diff displayName="src/index.js"
+ import _ from 'lodash';
++import printMe from './print.js';
+
+ function component() {
+   const element = document.createElement('div');
++  const btn = document.createElement('button');
+
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
++  btn.innerHTML = 'Click me and check the console!';
++  btn.onclick = printMe;
++
++  element.appendChild(btn);
++
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Update `dist/index.html` as well, preparing webpack to split out entries:
+
+```diff displayName="dist/index.html"
+ <!DOCTYPE html>
+ <html>
+   <head>
+     <meta charset="utf-8" />
+-    <title>Asset Management</title>
++    <title>Output Management</title>
++    <script src="./print.bundle.js"></script>
+   </head>
+   <body>
+-    <script src="bundle.js"></script>
++    <script src="./index.bundle.js"></script>
+   </body>
+ </html>
+```
+
+Now adjust the configuration. We'll add `src/print.js` as a new entry point named `print`, and we'll change the output so bundle names are generated dynamically from the entry point names:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+-  entry: './src/index.js',
++  entry: {
++    index: './src/index.js',
++    print: './src/print.js',
++  },
+   output: {
+-    filename: 'bundle.js',
++    filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+ };
+```
+
+Run `npm run build` and see what gets generated:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset index.bundle.js 69.5 KiB [emitted] [minimized] (name: index) 1 related asset
+asset print.bundle.js 316 bytes [emitted] [minimized] (name: print)
+runtime modules 1.36 KiB 7 modules
+cacheable modules 530 KiB
+  ./src/index.js 406 bytes [built] [code generated]
+  ./src/print.js 83 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 1996 ms
+```
+
+webpack generates `print.bundle.js` and `index.bundle.js`, both of which we referenced in `index.html`. Open `index.html` in your browser and click the button to see what happens.
+
+But what if we renamed one of our entry points, or added a new one? The generated bundles would be renamed on the next build, yet `index.html` would still reference the old names. Let's fix that with [`HtmlWebpackPlugin`](#TODO[/plugins/html-webpack-plugin]).
+
+> [!TIP]
+> If you inspected `print.bundle.js`, you might have noticed that it does not contain the `printMe` function. Instead, it contains only an [IIFE](#TODO[/concepts/why-webpack/#iifes---immediately-invoked-function-expressions]) with no observable side effects.
+>
+> This is because, in our current setup, webpack treats each entry point as a standalone program that runs when the bundle is loaded. Since `print.js` only exports a function and never calls `printMe()`, running it as its own entry requires no executable runtime code. As a result, [webpack can omit that code as an optimization](#TODO[/guides/tree-shaking/]) because it would have no observable effect.
+>
+> By contrast, since `index.js` imports and uses `printMe`, webpack includes that function directly in `index.bundle.js`. Remember that webpack is a module _bundler_, so `index.bundle.js` contains all the code it needs to run rather than unresolved import statements.
+>
+> The multiple entry points here exist solely to demonstrate output management and `HtmlWebpackPlugin`. In a real project, you'd typically avoid creating a separate entry point for a utility module like this. If you do have multiple entry points that share dependencies, see [Prevent Duplication](#TODO[/guides/code-splitting/#prevent-duplication]) in the Code Splitting guide.
+
+## Setting up `HtmlWebpackPlugin`
+
+First install the plugin and adjust `webpack.config.js`:
+
+```bash
+npm install --save-dev html-webpack-plugin
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
++import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
++  plugins: [
++    new HtmlWebpackPlugin({
++      title: 'Output Management',
++    }),
++  ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+ };
+```
+
+Before building, note that by default `HtmlWebpackPlugin` generates its own `index.html` file, even though we already have one in `dist/`. This means it will replace our `index.html` with a freshly generated one. Let's see what happens when we run `npm run build`:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset index.bundle.js 69.5 KiB [compared for emit] [minimized] (name: index) 1 related asset
+asset print.bundle.js 316 bytes [compared for emit] [minimized] (name: print)
+asset index.html 253 bytes [emitted]
+runtime modules 1.36 KiB 7 modules
+cacheable modules 530 KiB
+  ./src/index.js 406 bytes [built] [code generated]
+  ./src/print.js 83 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 2189 ms
+```
+
+If you open `index.html` in your editor, you'll see that `HtmlWebpackPlugin` created an entirely new file and added all the bundles automatically.
+
+To learn more about the features and options that `HtmlWebpackPlugin` provides, read up on it in the [`HtmlWebpackPlugin`](https://github.com/jantimon/html-webpack-plugin) repository.
+
+## Cleaning up the `/dist` folder
+
+As you may have noticed over the previous guides and examples, our `/dist` folder has become cluttered. webpack generates files and places them in `/dist` for you, but it doesn't track which files are actually still in use.
+
+In general, it's good practice to clean the `/dist` folder before each build so that only the files in use are generated. The [`output.clean`](#TODO[/configuration/output/#outputclean]) option takes care of this:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: {
+     index: './src/index.js',
+     print: './src/print.js',
+   },
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Output Management',
+     }),
+   ],
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
++    clean: true,
+   },
+ };
+```
+
+Run `npm run build` again and inspect the `/dist` folder. If everything went well, you should see only the files from the latest build and no leftover old files.
+
+## The manifest
+
+You might wonder how webpack and its plugins seem to "know" which files are being generated. The answer lies in the manifest that webpack keeps to track how all the modules map to the output bundles. If you're interested in managing webpack's [`output`](#TODO[/configuration/output]) in other ways, the manifest is a good place to start.
+
+The manifest data can be extracted into a JSON file for consumption using the [`ManifestPlugin`](#TODO[/plugins/manifest-plugin/]).
+
+We won't walk through a full example of using this plugin in your project, but you can read the [concept page](#TODO[/concepts/manifest]) and the [caching guide](#TODO[/guides/caching]) to learn how this ties into long-term caching.
+
+## Conclusion
+
+Now that you've learned how to add bundles to your HTML dynamically, dive into the [development guide](#TODO[/guides/development]). Or, if you want to explore more advanced topics, head over to the [code splitting guide](#TODO[/guides/code-splitting]).
diff --git a/pages/guides/core-workflows/production.md b/pages/guides/core-workflows/production.md
new file mode 100644
index 00000000..bacdebe8
--- /dev/null
+++ b/pages/guides/core-workflows/production.md
@@ -0,0 +1,201 @@
+---
+authors: henriquea,rajagopal4890,makuzaverite,markerikson,simon04,kisnows,chrisVillanueva,swapnilmishra,bring2dip,redian,skipjack,xgqfrms,kelset,xgirma,mehrdaad,SevenOutman,AnayaDesign,wizardofhogwarts,aholzner,EugeneHlushko,snitin315,Brennvo,ThierryRakotomanana,avivkeller
+---
+
+# Production
+
+In this guide, we'll explore some of the best practices and utilities for building a production site or application.
+
+> [!TIP]
+> This walkthrough builds on [Tree Shaking](#TODO[/guides/tree-shaking]) and [Development](#TODO[/guides/development]). Make sure you're familiar with the concepts and setup from those guides before continuing.
+
+## Setup
+
+The goals of _development_ and _production_ builds differ greatly. In development, we want strong source mapping and a localhost server with live reloading or hot module replacement. In production, our goals shift toward minified bundles, lighter-weight source maps, and optimized assets to improve load time. Because of this clear separation, we generally recommend writing **separate webpack configurations** for each environment.
+
+While we'll split out the production- and development-specific bits, we'll still keep a "common" configuration to stay DRY. To merge these configurations together, we'll use a utility called [`webpack-merge`](https://github.com/survivejs/webpack-merge). With the common configuration in place, we won't have to duplicate code in the environment-specific configurations.
+
+Let's start by installing `webpack-merge` and splitting out the work from previous guides:
+
+```bash
+npm install --save-dev webpack-merge
+```
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── package-lock.json
+- ├── webpack.config.js
++ ├── webpack.common.js
++ ├── webpack.dev.js
++ ├── webpack.prod.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
+  │   └── math.js
+  └── /node_modules
+```
+
+```diff displayName="webpack.common.js"
++ import path from 'node:path';
++ import { fileURLToPath } from 'node:url';
++ import HtmlWebpackPlugin from 'html-webpack-plugin';
++
++ const __filename = fileURLToPath(import.meta.url);
++ const __dirname = path.dirname(__filename);
++
++ export default {
++   entry: {
++     app: './src/index.js',
++   },
++   plugins: [
++     new HtmlWebpackPlugin({
++       title: 'Production',
++     }),
++   ],
++   output: {
++     filename: '[name].bundle.js',
++     path: path.resolve(__dirname, 'dist'),
++     clean: true,
++   },
++ };
+```
+
+```diff displayName="webpack.dev.js"
++ import { merge } from 'webpack-merge';
++ import common from './webpack.common.js';
++
++ export default merge(common, {
++   mode: 'development',
++   devtool: 'inline-source-map',
++   devServer: {
++     static: './dist',
++   },
++ });
+```
+
+```diff displayName="webpack.prod.js"
++ import { merge } from 'webpack-merge';
++ import common from './webpack.common.js';
++
++ export default merge(common, {
++   mode: 'production',
++ });
+```
+
+In `webpack.common.js`, we now have our `entry` and `output` configuration along with any plugins required by both environments. In `webpack.dev.js`, we've set `mode` to `development`, added the recommended `devtool` for that environment (strong source mapping), and configured our `devServer`. Finally, in `webpack.prod.js`, `mode` is set to `production`, which loads the [`MinimizerPlugin`](#TODO[/plugins/minimizer-webpack-plugin/]) first introduced in the [tree shaking](#TODO[/guides/tree-shaking/]) guide.
+
+Note the `merge()` calls in the environment-specific configurations, which pull in our common configuration in both `webpack.dev.js` and `webpack.prod.js`. `webpack-merge` offers a variety of advanced merging features, but we won't need any of them for this use case.
+
+## npm scripts
+
+Now let's update our npm scripts to use the new configuration files. The `start` script, which runs `webpack-dev-server`, will use `webpack.dev.js`, and the `build` script, which runs webpack to create a production build, will use `webpack.prod.js`:
+
+```diff displayName="package.json"
+  {
+    "name": "development",
+    "version": "1.0.0",
+    "description": "",
+    "main": "src/index.js",
+    "scripts": {
+-     "start": "webpack serve --open",
++     "start": "webpack serve --open --config webpack.dev.js",
+-     "build": "webpack"
++     "build": "webpack --config webpack.prod.js"
+    },
+    "keywords": [],
+    "author": "",
+    "license": "ISC",
+    "devDependencies": {
+      "css-loader": "^7.1.3",
+      "csv-loader": "^3.0.5",
+      "express": "^5.2.1",
+      "html-webpack-plugin": "^5.6.6",
+      "style-loader": "^4.0.0",
+      "webpack": "^5.105.0",
+      "webpack-cli": "^7.0.0",
+      "webpack-dev-middleware": "^8.0.3",
+      "webpack-dev-server": "^5.2.3",
+      "webpack-merge": "^6.0.1",
+      "xml-loader": "^1.2.1"
+    }
+  }
+```
+
+Feel free to run these scripts and watch how the output changes as we continue building out our production configuration.
+
+## Specify the mode
+
+Many libraries key off the `process.env.NODE_ENV` variable to decide what to include. For example, when `process.env.NODE_ENV` is not set to `'production'`, some libraries add extra logging and testing to ease debugging; when it is set to `'production'`, they may drop or add significant portions of code to optimize for your real users. Since webpack v4, specifying [`mode`](#TODO[/configuration/mode/]) automatically configures `process.env.NODE_ENV` for you via [`DefinePlugin`](https://github.com/webpack/webpack/blob/fcccd192ce550210186f84a7ca59ee4cd47a8b2d/lib/WebpackOptionsApply.js#L565):
+
+```diff displayName="webpack.prod.js"
+  import { merge } from 'webpack-merge';
+  import common from './webpack.common.js';
+
+  export default merge(common, {
+    mode: 'production',
+  });
+```
+
+> [!TIP]
+> Technically, `NODE_ENV` is a system environment variable that Node.js exposes to running scripts. By convention, server tools, build scripts, and client-side libraries use it to determine dev-versus-prod behavior. Contrary to expectations, `process.env.NODE_ENV` is not set automatically **within** the build script `webpack.config.js` when running webpack. As a result, conditionals like `process.env.NODE_ENV === 'production' ? '[name].[contenthash].bundle.js' : '[name].bundle.js'` won't work in webpack configurations unless you set `NODE_ENV` explicitly, for example with `NODE_ENV=production` via the CLI.
+
+If you use a library like [`react`](https://reactjs.org/), you should see a significant drop in bundle size after adding `DefinePlugin`. Also note that any of our local `/src` code can key off this as well, so the following check is valid:
+
+```diff displayName="src/index.js"
+  import { cube } from './math.js';
++
++ if (process.env.NODE_ENV !== 'production') {
++   console.log('Looks like we are in development mode!');
++ }
+
+  function component() {
+    const element = document.createElement('pre');
+
+    element.innerHTML = [
+      'Hello webpack!',
+      '5 cubed is equal to ' + cube(5)
+    ].join('\n\n');
+
+    return element;
+  }
+
+  document.body.appendChild(component());
+```
+
+## Minification
+
+webpack v4+ minifies your code by default in [production mode](#TODO[/configuration/mode/#mode-production]).
+
+While the [`MinimizerPlugin`](#TODO[/plugins/minimizer-webpack-plugin/]) is a great starting point and is used by default, other options exist:
+
+- [`ClosureWebpackPlugin`](https://github.com/webpack-contrib/closure-webpack-plugin)
+
+If you decide to try another minification plugin, make sure your choice also drops dead code as described in the [tree shaking](#TODO[/guides/tree-shaking]) guide, and provide it via [`optimization.minimizer`](#TODO[/configuration/optimization/#optimizationminimizer]).
+
+## Source mapping
+
+We encourage you to enable source maps in production, as they're useful for debugging as well as for running benchmark tests. That said, choose one with a reasonably quick build speed that's recommended for production use (see [`devtool`](#TODO[/configuration/devtool])). For this guide, we'll use the `source-map` option in production, as opposed to the `inline-source-map` we used in development:
+
+```diff displayName="webpack.prod.js"
+  import { merge } from 'webpack-merge';
+  import common from './webpack.common.js';
+
+  export default merge(common, {
+    mode: 'production',
++   devtool: 'source-map',
+  });
+```
+
+> [!TIP]
+> Avoid `inline-***` and `eval-***` in production, as they can increase bundle size and reduce overall performance.
+
+## Minimize CSS
+
+It's crucial to minimize your CSS for production. See the [Minimizing for Production](#TODO[/plugins/mini-css-extract-plugin/#minimizing-for-production]) section.
+
+## CLI alternatives
+
+Many of the options described above can be set as command-line arguments. For example, [`optimization.minimize`](#TODO[/configuration/optimization/#optimizationminimize]) can be set with `--optimization-minimize`, and [`mode`](#TODO[/configuration/mode/]) can be set with `--mode`. Run `npx webpack --help=verbose` for a full list of CLI arguments.
+
+While these shorthand methods are useful, we recommend setting these options in a webpack configuration file for greater configurability.
diff --git a/pages/guides/getting-started/concepts/configuration.md b/pages/guides/getting-started/concepts/configuration.md
new file mode 100644
index 00000000..64e2f5b7
--- /dev/null
+++ b/pages/guides/getting-started/concepts/configuration.md
@@ -0,0 +1,84 @@
+---
+authors: TheLarkInn,simon04,EugeneHlushko,byzyk,mr-baraiya,avivkeller
+---
+
+# Configuration
+
+You may have noticed that very few webpack configurations look exactly alike. That's because a webpack configuration file is simply a JavaScript file that exports a webpack [configuration](#TODO[/configuration/]). webpack then processes that configuration according to the properties you define on it.
+
+Since the configuration is a standard Node.js module, you can do all of the following:
+
+- Import other files with `require(...)` or `import`.
+- Pull in utilities from npm with `require(...)` or `import`.
+- Use JavaScript control flow expressions such as `?:`, `if`, and `for`.
+- Store frequently used values in constants or variables.
+- Write and call functions that generate part of the configuration.
+
+Use these capabilities whenever they make sense.
+
+The following practices, while technically possible, are best avoided:
+
+- Reading CLI arguments directly when using the webpack CLI. Doing so makes your configuration less portable and harder to maintain. Instead, write your own CLI or [use `--env`](#TODO[/api/cli/#env]) to pass environment variables.
+- Exporting non-deterministic values. Running webpack twice should always produce the same output files.
+- Writing long configurations. Split a large configuration into multiple files instead.
+
+> [!TIP]
+> The most important takeaway from this document is that there are many ways to format and style a webpack configuration. The key is to settle on something consistent that you and your team can understand and maintain.
+
+The examples below show how a webpack configuration can be both expressive and configurable, precisely because it is code.
+
+## Introductory configuration
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  mode: 'development',
+  entry: './foo.js',
+  output: {
+    path: path.resolve(__dirname, 'dist'),
+    filename: 'foo.bundle.js',
+  },
+};
+```
+
+See the [Configuration section](#TODO[/configuration/]) for every supported configuration option.
+
+## Using multiple configurations
+
+webpack supports exporting multiple configuration objects, which is useful when building different targets or outputs, for example separate client and server bundles.
+
+A single configuration is enough for many projects, but multiple configurations can help organize more complex setups.
+
+```js
+module.exports = [
+  {
+    entry: './src/client.js',
+    output: {
+      filename: 'client.bundle.js',
+    },
+  },
+  {
+    entry: './src/server.js',
+    output: {
+      filename: 'server.bundle.js',
+    },
+  },
+];
+```
+
+## Multiple targets
+
+In addition to exporting a single configuration as an object, a [function](#TODO[/configuration/configuration-types/#exporting-a-function]), or a [Promise](#TODO[/configuration/configuration-types/#exporting-a-promise]), you can export multiple configurations.
+
+See [Exporting multiple configurations](#TODO[/configuration/configuration-types/#exporting-multiple-configurations]).
+
+## Using other configuration languages
+
+webpack accepts configuration files written in several programming and data languages.
+
+See [Configuration Languages](#TODO[/configuration/configuration-languages/]).
diff --git a/pages/guides/getting-started/concepts/dependency-graph.md b/pages/guides/getting-started/concepts/dependency-graph.md
new file mode 100644
index 00000000..77d184fb
--- /dev/null
+++ b/pages/guides/getting-started/concepts/dependency-graph.md
@@ -0,0 +1,17 @@
+---
+authors: TheLarkInn,EugeneHlushko,avivkeller
+---
+
+# Dependency Graph
+
+Whenever one file depends on another, webpack treats that relationship as a _dependency_. This lets webpack handle non-code assets, such as images and web fonts, by exposing them as dependencies of your application too.
+
+When webpack processes your application, it begins with a list of modules defined on the command line or in its configuration file. Starting from these [_entry points_](#TODO[/concepts/entry-points/]), webpack recursively builds a _dependency graph_ that contains every module your application needs. It then bundles all of those modules into a small number of _bundles_ — often just one — for the browser to load.
+
+> [!TIP]
+> Bundling is especially powerful for _HTTP/1.1_ clients, because it reduces how often the app has to wait for the browser to open a new request. For _HTTP/2_, you can additionally apply [Code Splitting](#TODO[/guides/code-splitting/]) for the best results.
+
+## Further reading
+
+- [HTTP2 Aggressive Splitting Example](https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-splitting)
+- [webpack & HTTP/2](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6)
diff --git a/pages/guides/getting-started/concepts/entry-points.md b/pages/guides/getting-started/concepts/entry-points.md
new file mode 100644
index 00000000..47b37154
--- /dev/null
+++ b/pages/guides/getting-started/concepts/entry-points.md
@@ -0,0 +1,223 @@
+---
+authors: TheLarkInn,chrisVillanueva,byzyk,sokra,EugeneHlushko,Zearin,chenxsan,adyjs,anshumanv,ritikbanger,saishankar404,avivkeller
+---
+
+# Entry Points
+
+As mentioned in [Getting Started](#TODO[/guides/getting-started/#using-a-configuration]), there are several ways to define the `entry` property in your webpack configuration. This page walks through the ways you can configure `entry` and explains why each may be useful.
+
+In simple terms, an entry point tells webpack where to start building its internal dependency graph. Starting from this file, webpack recursively follows every imported module and asset to determine what belongs in the final bundle.
+
+The result of this process is later written to disk according to the `output` configuration, which controls where and how the bundled files are emitted.
+
+> [!TIP]
+> When you run webpack without a configuration file, the entry defaults to `'./src/index.js'`. If that file is missing — even when your `src/` directory exists — webpack throws:
+>
+> **`ERROR in Entry module not found: Error: Can't resolve './src'`**
+>
+> The error mentions `'./src'` rather than `'./src/index.js'` because webpack resolves the directory first and then fails to find `index.js` inside it. To use a different entry filename, configure the `entry` option as shown in the sections below.
+
+## Single entry (shorthand) syntax
+
+Usage: `entry: string | [string]`
+
+- `string`: a single entry file.
+- `[string]`: multiple entry files.
+
+```js displayName="webpack.config.js"
+export default {
+  entry: './path/to/my/entry/file.js',
+};
+```
+
+The single entry syntax for the `entry` property is shorthand for:
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    main: './path/to/my/entry/file.js',
+  },
+};
+```
+
+You can also pass an array of file paths to the `entry` property, which creates what is known as a **"multi-main entry"**. This is useful when you want to inject several dependent files together and graph their dependencies into a single chunk.
+
+```js displayName="webpack.config.js"
+export default {
+  entry: ['./src/file_1.js', './src/file_2.js'],
+};
+```
+
+When an array is provided for an entry point, webpack still creates a **single entry chunk**. All modules in the array are loaded in the given order and combined into the same dependency graph.
+
+This pattern is commonly used to inject extra code before the main application entry — such as polyfills or development-only tooling — without manually importing it in the application source.
+
+**Example: injecting a polyfill**
+
+```js
+export default {
+  entry: {
+    main: ['@babel/polyfill', './src/index.js'],
+  },
+};
+```
+
+The single entry syntax is a great choice when you want to quickly set up a webpack configuration for an application or tool with one entry point, such as a library. However, it offers little flexibility for extending or scaling your configuration.
+
+## Object syntax
+
+Usage: `entry: { <entryChunkName> string | [string] } | {}`
+
+- `<entryChunkName>`: the name of the entry chunk.
+- `string`: a single entry file.
+- `[string]`: multiple entry files.
+- `{}`: an empty object.
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    app: './src/app.js',
+    adminApp: './src/adminApp.js',
+  },
+};
+```
+
+The object syntax is more verbose, but it is the most scalable way to define entries in your application.
+
+> [!TIP]
+> **"Scalable webpack configurations"** are ones that can be reused and combined with other partial configurations. This is a popular technique for separating concerns by environment, build target, and runtime. The partial configurations are then merged with specialized tools like [webpack-merge](https://github.com/survivejs/webpack-merge).
+
+> [!TIP]
+> You can pass an empty object `{}` to `entry` when your only entry points are generated by plugins.
+
+### EntryDescription object
+
+An object describing an entry point. You can specify the following properties:
+
+- `dependOn`: the entry points that this entry point depends on. They must be loaded before this entry point is loaded.
+- `filename`: the name of each output file on disk.
+- `import`: the module(s) loaded at startup.
+- `library`: specifies [library options](#TODO[/configuration/output/#outputlibrary]) to bundle a library from the current entry.
+- `runtime`: the name of the runtime chunk. When set, a new runtime chunk is created. Since webpack 5.43.0, it can be set to `false` to avoid creating a new runtime chunk.
+- `publicPath`: a public URL for this entry's output files when they are referenced in a browser. See also [output.publicPath](#TODO[/configuration/output/#outputpublicpath]).
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    a2: 'dependingfile.js',
+    b2: {
+      dependOn: 'a2',
+      import: './src/app.js',
+    },
+  },
+};
+```
+
+`runtime` and `dependOn` must not be used together on a single entry, so the following configuration is invalid and throws an error:
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    a2: './a',
+    b2: {
+      runtime: 'x2',
+      dependOn: 'a2',
+      import: './b',
+    },
+  },
+};
+```
+
+`runtime` must not point to an existing entry point name either. The configuration below throws an error:
+
+```js
+export default {
+  entry: {
+    a1: './a',
+    b1: {
+      runtime: 'a1',
+      import: './b',
+    },
+  },
+};
+```
+
+Finally, `dependOn` must not be circular. The following example also throws an error:
+
+```js
+export default {
+  entry: {
+    a3: {
+      import: './a',
+      dependOn: 'b3',
+    },
+    b3: {
+      import: './b',
+      dependOn: 'a3',
+    },
+  },
+};
+```
+
+## Scenarios
+
+Here are some common entry configurations and their real-world use cases.
+
+### Separate app and vendor entries
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    main: './src/app.js',
+    vendor: './src/vendor.js',
+  },
+};
+```
+
+When building in `production` mode:
+
+```js displayName="webpack.prod.js"
+export default {
+  output: {
+    filename: '[name].[contenthash].bundle.js', // e.g. main.abc123.bundle.js, vendor.abc123.bundle.js
+  },
+};
+```
+
+When building in `development` mode:
+
+```js displayName="webpack.dev.js"
+export default {
+  output: {
+    filename: '[name].bundle.js', // e.g. main.bundle.js, vendor.bundle.js
+  },
+};
+```
+
+**What does this do?** It tells webpack that we want two separate entry points, as in the example above.
+
+**Why?** With this setup, you can import libraries or files that rarely change (such as Bootstrap, jQuery, or images) inside `vendor.js`, and they will be bundled together into their own chunk. Because the content hash stays the same, the browser can cache them separately, reducing load time.
+
+> [!TIP]
+> In webpack versions earlier than 4, it was common to add vendors as a separate entry point so they would be compiled into a separate file (in combination with the `CommonsChunkPlugin`).
+>
+> This is discouraged in webpack 4 and later. Instead, the [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) option takes care of separating vendor and app modules into a separate file. **Do not** create an entry for vendors or anything else that is not the starting point of execution.
+
+### Multi-page application
+
+```js displayName="webpack.config.js"
+export default {
+  entry: {
+    pageOne: './src/pageOne/index.js',
+    pageTwo: './src/pageTwo/index.js',
+    pageThree: './src/pageThree/index.js',
+  },
+};
+```
+
+**What does this do?** It tells webpack that we want three separate dependency graphs, as in the example above.
+
+**Why?** In a multi-page application, the server fetches a new HTML document for each page. The page reloads that document and its assets are re-downloaded. This gives us a unique opportunity to use techniques like [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) to create bundles of code shared across pages. Multi-page applications that reuse a lot of code between entry points benefit greatly from these techniques as the number of entry points grows.
+
+> [!TIP]
+> As a rule of thumb, use exactly one entry point per HTML document. See the issue [described here](https://bundlers.tooling.report/code-splitting/multi-entry/#webpack) for more details.
diff --git a/pages/guides/getting-started/concepts/hot-module-replacement.md b/pages/guides/getting-started/concepts/hot-module-replacement.md
new file mode 100644
index 00000000..9c7e939a
--- /dev/null
+++ b/pages/guides/getting-started/concepts/hot-module-replacement.md
@@ -0,0 +1,64 @@
+---
+authors: kryptokinght,SpaceK33z,sokra,GRardB,rouzbeh84,skipjack,avivkeller
+---
+
+# Hot Module Replacement
+
+Hot Module Replacement (HMR) exchanges, adds, or removes [modules](#TODO[/concepts/modules/]) while an application is running, without a full reload. It can significantly speed up development in several ways:
+
+- It preserves application state that would otherwise be lost during a full reload.
+- It saves valuable development time by updating only what changed.
+- It updates the browser instantly when CSS or JavaScript source changes, which feels almost like editing styles directly in the browser's dev tools.
+
+## How it works
+
+Let's look at HMR from several different viewpoints to understand exactly how it works.
+
+### In the application
+
+The following steps allow modules to be swapped in and out of a running application:
+
+1. The application asks the HMR runtime to check for updates.
+2. The runtime asynchronously downloads the updates and notifies the application.
+3. The application then asks the runtime to apply the updates.
+4. The runtime applies the updates synchronously.
+
+You can configure HMR so that this process happens automatically, or you can require user interaction before updates are applied.
+
+### In the compiler
+
+Beyond the usual assets, the compiler emits an "update" that allows moving from the previous version to the new one. An update has two parts:
+
+1. The updated [manifest](#TODO[/concepts/manifest]) (JSON).
+2. One or more updated chunks (JavaScript).
+
+The manifest contains the new compilation hash and a list of all updated chunks. Each chunk contains the new code for its updated modules, or a flag indicating that a module was removed.
+
+The compiler keeps module IDs and chunk IDs consistent between builds. It usually stores these IDs in memory (for example, with [webpack-dev-server](#TODO[/configuration/dev-server/])), but they can also be stored in a JSON file.
+
+### In a module
+
+HMR is an opt-in feature that only affects modules containing HMR code. One example is patching styles through [`style-loader`](https://github.com/webpack/style-loader). For patching to work, `style-loader` implements the HMR interface: when it receives an update through HMR, it replaces the old styles with the new ones.
+
+Similarly, by implementing the HMR interface in a module, you can describe what should happen when that module is updated. In most cases, however, you do not need to write HMR code in every module. If a module has no HMR handlers, the update bubbles up. This means a single handler can update a whole module tree. When any module in the tree is updated, the entire set of dependencies is reloaded.
+
+See the [HMR API page](#TODO[/api/hot-module-replacement]) for details on the `module.hot` interface.
+
+### In the runtime
+
+Here things get a bit more technical. If you're not interested in the internals, feel free to skip ahead to the [HMR API page](#TODO[/api/hot-module-replacement]) or the [HMR guide](#TODO[/guides/hot-module-replacement]).
+
+For the module system runtime, additional code is emitted to track each module's `parents` and `children`. On the management side, the runtime supports two methods: `check` and `apply`.
+
+A `check` makes an HTTP request to the update manifest. If the request fails, no update is available. If it succeeds, the list of updated chunks is compared with the list of currently loaded chunks. For each loaded chunk, the corresponding update chunk is downloaded, and all module updates are stored in the runtime. Once every update chunk has been downloaded and is ready to apply, the runtime switches into the `ready` state.
+
+The `apply` method flags all updated modules as invalid. Each invalid module needs an update handler in itself or in one of its parents. Otherwise, the invalid flag bubbles up and invalidates the parents too. Each bubble continues until it reaches the application's entry point or a module with an update handler, whichever comes first. If it bubbles up from an entry point, the process fails.
+
+Afterward, all invalid modules are disposed (via their dispose handlers) and unloaded. The current hash is then updated and all `accept` handlers are called. The runtime switches back to the `idle` state, and everything continues as normal.
+
+## Get started
+
+HMR can be used in development as a replacement for LiveReload. [webpack-dev-server](#TODO[/configuration/dev-server/]) supports a `hot` mode in which it tries to update with HMR before falling back to reloading the whole page. See the [Hot Module Replacement guide](#TODO[/guides/hot-module-replacement]) for details.
+
+> [!TIP]
+> As with many other features, webpack's power lies in its customizability. There are _many_ ways to configure HMR depending on a project's needs. For most purposes, though, `webpack-dev-server` is a good fit and will get you started with HMR quickly.
diff --git a/pages/guides/getting-started/concepts/index.md b/pages/guides/getting-started/concepts/index.md
new file mode 100644
index 00000000..b740ac78
--- /dev/null
+++ b/pages/guides/getting-started/concepts/index.md
@@ -0,0 +1,162 @@
+---
+authors: TheLarkInn,jhnns,grgur,johnstew,jimrfenner,TheDutchCoder,adambraimbridge,EugeneHlushko,jeremenichelli,arjunsajeev,byzyk,yairhaimo,farskid,LukeMwila,Jalitha,muhmushtaha,chenxsan,RyanGreyling2,saishankar404,avivkeller
+---
+
+# Concepts
+
+At its core, **webpack** is a _static module bundler_ for modern JavaScript applications. When webpack processes your application, it internally builds a [dependency graph](#TODO[/concepts/dependency-graph/]) from one or more _entry points_ and then combines every module your project needs into one or more _bundles_, which are static assets that serve your content.
+
+> [!TIP]
+> Learn more about JavaScript modules and webpack modules [here](#TODO[/concepts/modules]).
+
+Since version 4.0.0, **webpack does not require a configuration file** to bundle your project. Even so, it is [incredibly configurable](#TODO[/configuration]) to better fit your needs.
+
+To get started, you only need to understand its **core concepts**:
+
+- [Entry](#entry)
+- [Output](#output)
+- [Loaders](#loaders)
+- [Plugins](#plugins)
+- [Mode](#mode)
+- [Browser Compatibility](#browser-compatibility)
+
+This document gives a **high-level** overview of these concepts while linking to more detailed, concept-specific use cases.
+
+For a deeper understanding of the ideas behind module bundlers and how they work under the hood, consult these resources:
+
+- [Manually Bundling an Application](https://www.youtube.com/watch?v=UNMkLHzofQI)
+- [Live Coding a Basic Module Bundler](https://www.youtube.com/watch?v=Gc9-7PBqOC8)
+- [Detailed Explanation of a Basic Module Bundler](https://github.com/ronami/minipack)
+
+## Entry
+
+An **entry point** tells webpack which module to use to begin building its internal [dependency graph](#TODO[/concepts/dependency-graph/]). From there, webpack determines which other modules and libraries that entry point depends on, both directly and indirectly.
+
+By default the entry is `./src/index.js`, but you can specify a different entry point — or multiple — by setting the [`entry` property in the webpack configuration](#TODO[/configuration/entry-context/#entry]). For example:
+
+```js displayName="webpack.config.js"
+export default {
+  entry: './path/to/my/entry/file.js',
+};
+```
+
+> [!TIP]
+> When you run webpack without a configuration file, the entry defaults to `'./src/index.js'`. If that file does not exist — even when your `src/` directory does — webpack throws:
+>
+> **`ERROR in Entry module not found: Error: Can't resolve './src'`**
+>
+> The error mentions `'./src'` rather than `'./src/index.js'` because webpack resolves the directory first and then fails to find the default `index.js` inside it. To use a different entry filename, add a `webpack.config.js` as shown in the example above.
+
+> [!TIP]
+> Learn more in the [entry points](#TODO[/concepts/entry-points]) section.
+
+## Output
+
+The **output** property tells webpack where to emit the _bundles_ it creates and how to name those files. It defaults to `./dist/main.js` for the main output file and to the `./dist` folder for any other generated file.
+
+You can configure this part of the process with an `output` field in your configuration:
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './path/to/my/entry/file.js',
+  output: {
+    path: path.resolve(__dirname, 'dist'),
+    filename: 'my-first-webpack.bundle.js',
+  },
+};
+```
+
+In the example above, the `output.filename` and `output.path` properties tell webpack the name of our bundle and where to emit it. If you're wondering about the `path` module imported at the top, it is a core [Node.js module](https://nodejs.org/api/modules.html) used to manipulate file paths.
+
+> [!TIP]
+> The `output` property has [many more configurable features](#TODO[/configuration/output]). To learn about the concepts behind it, [read more in the output section](#TODO[/concepts/output]).
+
+## Loaders
+
+Out of the box, webpack only understands JavaScript and JSON files. **Loaders** let webpack process other types of files and convert them into valid [modules](#TODO[/concepts/modules]) that your application can consume and that can be added to the dependency graph.
+
+> [!WARNING]
+> One of webpack's distinctive features is the ability to `import` any type of module, for example `.css` files, which other bundlers or task runners may not support. We feel this extension of the language is warranted, because it lets developers build a more accurate dependency graph.
+
+At a high level, **loaders** have two properties in your webpack configuration:
+
+1. The `test` property identifies which file or files should be transformed.
+2. The `use` property indicates which loader should perform the transformation.
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+
+export default {
+  output: {
+    filename: 'my-first-webpack.bundle.js',
+  },
+  module: {
+    rules: [{ test: /\.js$/, use: 'babel-loader' }],
+  },
+};
+```
+
+The configuration above defines a `rules` property with a single rule that has the two required properties `test` and `use`. This tells webpack's compiler the following:
+
+> "Hey webpack compiler, when you come across a path that resolves to a '.js' file inside a `require()`/`import` statement, **use** the `babel-loader` to transform it before you add it to the bundle."
+
+> [!WARNING]
+> Remember that when you define rules in your webpack configuration, you define them under `module.rules`, not `rules`. webpack will warn you if you get this wrong.
+
+> [!WARNING]
+> Keep in mind that when you use a regular expression to match files, you must not quote it. For example, `/\.txt$/` is not the same as `'/\.txt$/'` or `"/\.txt$/"`. The former tells webpack to match any file ending in `.txt`, while the latter tells webpack to match a single file with the absolute path `'.txt'`, which is likely not your intention.
+
+You can learn more about including loaders in the [loaders section](#TODO[/concepts/loaders]).
+
+## Plugins
+
+While loaders transform certain types of modules, plugins can perform a much wider range of tasks, such as bundle optimization, asset management, and injecting environment variables.
+
+> [!TIP]
+> Check out the [plugin interface](#TODO[/api/plugins]) and how to use it to extend webpack's capabilities.
+
+To use a plugin, you `import` it and add it to the `plugins` array. Most plugins are customizable through options. Since you can use a plugin multiple times in a configuration for different purposes, you create an instance of it by calling it with the `new` operator.
+
+```js displayName="webpack.config.js"
+import HtmlWebpackPlugin from 'html-webpack-plugin';
+import webpack from 'webpack'; // to access built-in plugins
+
+export default {
+  module: {
+    rules: [{ test: /\.js$/, use: 'babel-loader' }],
+  },
+  plugins: [new HtmlWebpackPlugin({ template: './src/index.html' })],
+};
+```
+
+In the example above, the `html-webpack-plugin` generates an HTML file for your application and automatically injects all of your generated bundles into it.
+
+> [!TIP]
+> webpack provides many plugins out of the box. Check out the [list of plugins](#TODO[/plugins]).
+
+Using plugins in your webpack configuration is straightforward, but there are many use cases worth exploring further. [Learn more about them here](#TODO[/concepts/plugins]).
+
+## Mode
+
+By setting the `mode` parameter to `development`, `production`, or `none`, you can enable webpack's built-in optimizations for the corresponding environment. The default value is `production`.
+
+```js
+export default {
+  mode: 'production',
+};
+```
+
+Learn more about the [mode configuration here](#TODO[/configuration/mode]) and which optimizations each value enables.
+
+## Browser Compatibility
+
+webpack supports all browsers that are [ES5-compliant](https://compat-table.github.io/compat-table/es5/); IE8 and below are not supported. webpack needs `Promise` for [`import()` and `require.ensure()`](#TODO[/guides/code-splitting/#dynamic-imports]). To support older browsers, you will need to [load a polyfill](#TODO[/guides/shimming/]) before using these expressions.
+
+## Environment
+
+webpack 5 requires Node.js version 10.13.0 or later.
diff --git a/pages/guides/getting-started/concepts/loaders.md b/pages/guides/getting-started/concepts/loaders.md
new file mode 100644
index 00000000..8b9396d2
--- /dev/null
+++ b/pages/guides/getting-started/concepts/loaders.md
@@ -0,0 +1,122 @@
+---
+authors: manekinekko,evenstensberg,SpaceK33z,gangachris,TheLarkInn,simon04,jhnns,byzyk,debs-obrien,EugeneHlushko,wizardofhogwarts,lukasgeiter,furkle,jamesgeorge007,textbook,avivkeller
+---
+
+# Loaders
+
+Loaders are transformations applied to the source code of a module. They let you pre-process files as you `import` or "load" them, so loaders are a bit like the "tasks" in other build tools and offer a powerful way to handle front-end build steps. A loader can transform a file from another language (such as TypeScript) into JavaScript, or load an inline image as a data URL. Loaders even let you `import` CSS files directly from your JavaScript modules.
+
+## Example
+
+For instance, you can use loaders to tell webpack to load a CSS file or to convert TypeScript to JavaScript. Start by installing the loaders you need:
+
+```bash
+npm install --save-dev css-loader ts-loader
+```
+
+Then instruct webpack to use [`css-loader`](#TODO[/loaders/css-loader]) for every `.css` file and [`ts-loader`](https://github.com/TypeStrong/ts-loader) for every `.ts` file:
+
+```js displayName="webpack.config.js"
+export default {
+  module: {
+    rules: [
+      { test: /\.css$/, use: 'css-loader' },
+      { test: /\.ts$/, use: 'ts-loader' },
+    ],
+  },
+};
+```
+
+> [!TIP]
+> Although the examples above use a loader to load CSS files, webpack has an experimental option ([`experiments.css`](https://webpack.js.org/configuration/experiments/)) that lets webpack process CSS and automatically inject the styles into the webpage.
+
+## Using loaders
+
+There are two ways to use loaders in your application:
+
+- [Configuration](#configuration) (recommended): specify them in your `webpack.config.js` file.
+- [Inline](#inline): specify them explicitly in each `import` statement.
+
+Note that loaders could be used from the CLI in webpack v4, but that feature was deprecated in webpack v5.
+
+### Configuration
+
+[`module.rules`](#TODO[/configuration/module/#modulerules]) lets you specify several loaders within your webpack configuration. This is a concise way to declare loaders, helps keep your code clean, and gives you a full overview of each loader.
+
+Loaders are evaluated and executed from right to left (or from bottom to top). In the example below, execution starts with `sass-loader`, continues with `css-loader`, and finally ends with `style-loader`. See [Loader features](#loader-features) for more information about loader order.
+
+```js
+export default {
+  module: {
+    rules: [
+      {
+        test: /\.css$/,
+        use: [
+          { loader: 'style-loader' },
+          {
+            loader: 'css-loader',
+            options: {
+              modules: true,
+            },
+          },
+          { loader: 'sass-loader' },
+        ],
+      },
+    ],
+  },
+};
+```
+
+### Inline
+
+You can specify loaders directly in an `import` statement, or in any [equivalent "importing" method](#TODO[/api/module-methods]). Separate loaders from the resource with `!`. Each part is resolved relative to the current directory.
+
+> [!TIP]
+> The `loader1!loader2!./file` syntax is shown here only for illustration. In most projects, prefer configuring loaders via `module.rules` and importing styles for their side effects (for example, `import "./styles.css"`).
+
+```js
+import * as styles from 'style-loader!css-loader?modules!./styles.css';
+```
+
+You can override any loaders, preLoaders, and postLoaders from the [configuration](#TODO[/configuration]) by prefixing the inline `import` statement:
+
+- Prefixing with `!` disables all configured normal loaders:
+
+  ```js
+  import * as styles from '!style-loader!css-loader?modules!./styles.css';
+  ```
+
+- Prefixing with `!!` disables all configured loaders (preLoaders, loaders, and postLoaders):
+
+  ```js
+  import * as styles from '!!style-loader!css-loader?modules!./styles.css';
+  ```
+
+- Prefixing with `-!` disables all configured preLoaders and loaders, but not postLoaders:
+
+  ```js
+  import * as styles from '-!style-loader!css-loader?modules!./styles.css';
+  ```
+
+Options can be passed as a query parameter, such as `?key=value&foo=bar`, or as a JSON object, such as `?{"key":"value","foo":"bar"}`.
+
+> [!TIP]
+> Use `module.rules` whenever possible. It reduces boilerplate in your source code and makes it easier to debug or locate a loader if something goes wrong.
+
+## Loader features
+
+- Loaders can be chained. Each loader in the chain applies its transformations to the processed resource. A chain is executed in reverse order: the first loader passes its result (the resource with its transformations applied) to the next one, and so on. webpack expects the last loader in the chain to return JavaScript.
+- Loaders can be synchronous or asynchronous.
+- Loaders run in Node.js and can do anything that's possible there.
+- Loaders can be configured with an `options` object. Setting options with `query` parameters is still supported but deprecated.
+- Normal modules can export a loader in addition to the usual `main`, via the `loader` field in `package.json`.
+- Plugins can give loaders additional features.
+- Loaders can emit extra, arbitrary files.
+
+Loaders let you customize the output through their preprocessing functions. This gives you the flexibility to include fine-grained logic such as compression, packaging, language translation, and [more](#TODO[/loaders]).
+
+## Resolving loaders
+
+Loaders follow the standard [module resolution](#TODO[/concepts/module-resolution/]). In most cases they are loaded from the [module path](#TODO[/concepts/module-resolution/#module-paths]) (think `npm install` and `node_modules`).
+
+A loader module is expected to export a function and be written in Node.js-compatible JavaScript. Loaders are most commonly managed with npm, but you can also keep custom loaders as files within your application. By convention, loaders are usually named `xxx-loader` (for example, `json-loader`). See [Writing a Loader](#TODO[/contribute/writing-a-loader/]) for more information.
diff --git a/pages/guides/getting-started/concepts/manifest.md b/pages/guides/getting-started/concepts/manifest.md
new file mode 100644
index 00000000..35a43bfe
--- /dev/null
+++ b/pages/guides/getting-started/concepts/manifest.md
@@ -0,0 +1,37 @@
+---
+authors: skipjack,EugeneHlushko,avivkeller
+---
+
+# The Manifest
+
+A typical application or site built with webpack contains three main kinds of code:
+
+1. The source code that you, and perhaps your team, have written.
+2. Any third-party library or "vendor" code that your source depends on.
+3. A webpack runtime and **manifest** that orchestrate the interaction between all of the modules.
+
+This article focuses on the last of these three parts: the runtime and, in particular, the manifest.
+
+## Runtime
+
+The runtime, together with the manifest data, is all the code webpack needs to wire up your modularized application while it runs in the browser. It contains the loading and resolving logic that connects your modules as they interact. This includes connecting modules already loaded into the browser, as well as the logic to lazy-load the ones that haven't loaded yet.
+
+## Manifest
+
+Once your application reaches the browser as an `index.html` file, some bundles and a variety of other assets must be loaded and linked together somehow. That `/src` directory you carefully laid out is now bundled, minified, and maybe even split into smaller chunks for lazy-loading by webpack's [`optimization`](#TODO[/configuration/optimization/]). So how does webpack manage the interaction between all of your required modules? This is where the manifest data comes in.
+
+As the compiler enters, resolves, and maps out your application, it keeps detailed notes on all of your modules. This collection of data is called the "manifest," and it's what the runtime uses to resolve and load modules once they've been bundled and shipped to the browser. No matter which [module syntax](#TODO[/api/module-methods]) you chose, those `import` and `require` statements have now become `__webpack_require__` methods that point to module identifiers. Using the data in the manifest, the runtime can find out where to retrieve the modules behind those identifiers.
+
+## The problem
+
+So now you have a little insight into how webpack works behind the scenes. "But how does this affect me?" you might ask. Most of the time, it doesn't. The runtime does its thing using the manifest, and everything appears to work magically once your application hits the browser. However, once you decide to improve performance by taking advantage of browser caching, this process suddenly becomes important to understand.
+
+By using content hashes in your bundle file names, you can signal to the browser when a file's content has changed, which invalidates the cache. Once you start doing this, though, you'll immediately notice some odd behavior: certain hashes change even when their content apparently does not. This is caused by the injection of the runtime and manifest, which changes with every build.
+
+See [the manifest section](#TODO[/guides/output-management/#the-manifest]) of our _Output management_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long-term caching.
+
+## Further reading
+
+- [Separating a Manifest](https://survivejs.com/webpack/optimizing/separating-manifest/)
+- [Predictable Long Term Caching with webpack](https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31)
+- [Caching](#TODO[/guides/caching/])
diff --git a/pages/guides/getting-started/concepts/module-federation.md b/pages/guides/getting-started/concepts/module-federation.md
new file mode 100644
index 00000000..00d62bfe
--- /dev/null
+++ b/pages/guides/getting-started/concepts/module-federation.md
@@ -0,0 +1,373 @@
+---
+authors: sokra,chenxsan,EugeneHlushko,jamesgeorge007,ScriptedAlchemy,snitin315,XiaofengXie16,KyleBastien,Alevale,burhanuday,RexSkz,avivkeller
+---
+
+# Module Federation
+
+## Motivation
+
+Multiple separate builds should be able to form a single application. These separate builds act like containers that can expose and consume code among themselves, producing one unified application.
+
+This is often called Micro-Frontends, but it is not limited to that pattern.
+
+<!-- TODO: StackBlitzPreview example="module-federation?terminal=start&terminal=" -->
+
+## Low-level concepts
+
+We distinguish between local and remote modules. Local modules are regular modules that are part of the current build. Remote modules are not part of the current build; they are loaded at runtime from a remote container.
+
+Loading a remote module is an asynchronous operation. When you use a remote module, that asynchronous operation is placed in the next chunk-loading operation(s) that sit between the remote module and the entry point. You cannot use a remote module without a chunk-loading operation.
+
+A chunk-loading operation is usually an `import()` call, but older constructs such as `require.ensure` or `require([...])` are supported as well.
+
+A container is created through a container entry, which exposes asynchronous access to specific modules. That access is split into two steps:
+
+1. Loading the module (asynchronous).
+2. Evaluating the module (synchronous).
+
+Step 1 happens during chunk loading. Step 2 happens during module evaluation, interleaved with other local and remote modules. This way, evaluation order is unaffected by converting a module from local to remote or vice versa.
+
+Containers can be nested, and a container can use modules from other containers. Circular dependencies between containers are also possible.
+
+## High-level concepts
+
+Each build acts as a container and also consumes other builds as containers. This way, each build can access any other exposed module by loading it from its container.
+
+Shared modules are modules that are both overridable and provided as overrides to nested containers. They usually point to the same module in each build, for example the same library.
+
+The `packageName` option lets you set a package name to look up a `requiredVersion`. It is inferred automatically from the module requests by default; set `requiredVersion` to `false` to disable automatic inference.
+
+## Building blocks
+
+### `ContainerPlugin` (low level)
+
+This plugin creates an additional container entry with the specified exposed modules.
+
+### `ContainerReferencePlugin` (low level)
+
+This plugin adds specific references to containers as externals and allows importing remote modules from those containers. It also calls the `override` API of these containers to provide overrides to them. Local overrides (via `__webpack_override__` or the `override` API, when the build is also a container) and specified overrides are provided to all referenced containers.
+
+### `ModuleFederationPlugin` (high level)
+
+[`ModuleFederationPlugin`](#TODO[/plugins/module-federation-plugin]) combines `ContainerPlugin` and `ContainerReferencePlugin`.
+
+## Concept goals
+
+- It should be possible to expose and consume any module type that webpack supports.
+- Chunk loading should load everything needed in parallel (on the web, in a single round trip to the server).
+- Control flows from the consumer to the container:
+  - Overriding modules is a one-directional operation.
+  - Sibling containers cannot override each other's modules.
+- The concept should be environment-independent and usable on the web, in Node.js, and elsewhere.
+- Relative and absolute requests in `shared`:
+  - Are always provided, even if not used.
+  - Resolve relative to `config.context`.
+  - Do not use a `requiredVersion` by default.
+- Module requests in `shared`:
+  - Are only provided when they are used.
+  - Match all used equal module requests in your build.
+  - Provide all matching modules.
+  - Extract `requiredVersion` from the `package.json` at that position in the graph.
+  - Can provide and consume multiple different versions when you have nested `node_modules`.
+- Module requests with a trailing `/` in `shared` match all module requests with that prefix.
+
+## Use cases
+
+### Separate builds per page
+
+Each page of a Single Page Application is exposed from a container build in a separate build. The application shell is also a separate build that references all pages as remote modules. This way, each page can be deployed separately. The application shell is deployed when routes are updated or new routes are added. The application shell defines commonly used libraries as shared modules to avoid duplicating them across the page builds.
+
+### Component library as a container
+
+Many applications share a common component library, which can be built as a container with each component exposed. Each application consumes components from that container. Changes to the component library can be deployed separately, without redeploying every application. The applications automatically use the up-to-date version of the component library.
+
+## Dynamic remote containers
+
+The container interface supports `get` and `init` methods. `init` is an `async`-compatible method called with a single argument: the shared scope object. This object is used as the shared scope in the remote container and is filled with the modules provided by a host. You can use it to connect remote containers to a host container dynamically at runtime.
+
+```js displayName="init.js"
+(async () => {
+  // Initializes the shared scope. Fills it with known provided modules from this build and all remotes.
+  await __webpack_init_sharing__('default');
+  const container = globalThis.someContainer; // or get the container somewhere else
+  // Initialize the container; it may provide shared modules.
+  await container.init(__webpack_share_scopes__.default);
+  const module = await container.get('./module');
+})();
+```
+
+> [!TIP]
+> A **container** is the remote container entry object exposed by a federated build, usually through that remote's `remoteEntry.js`. It provides the `get` and `init` methods shown here. In examples like `window[scope]` or `globalThis.someContainer`, the container is expected to exist only after the remote container script has already loaded.
+
+The container tries to provide shared modules, but if a shared module has already been used, a warning is issued and the newly provided shared module is ignored. The container may still use it as a fallback.
+
+This way, you could dynamically load an A/B test that provides a different version of a shared module.
+
+> [!TIP]
+> Ensure you have loaded the container before attempting to dynamically connect a remote container.
+
+Example:
+
+```js displayName="init.js"
+function loadComponent(scope, module) {
+  return async () => {
+    // Initializes the shared scope. Fills it with known provided modules from this build and all remotes.
+    await __webpack_init_sharing__('default');
+    const container = window[scope]; // the remote container exposed by the loaded remoteEntry.js script
+    // Initialize the container; it may provide shared modules.
+    await container.init(__webpack_share_scopes__.default);
+    const factory = await window[scope].get(module);
+    const Module = factory();
+    return Module;
+  };
+}
+
+loadComponent('abtests', 'test123');
+```
+
+[See the full implementation](https://github.com/module-federation/module-federation-examples/tree/master/advanced-api/dynamic-remotes).
+
+## Promise-based dynamic remotes
+
+Remotes are generally configured using URLs, as in this example:
+
+```js
+export default {
+  plugins: [
+    new ModuleFederationPlugin({
+      name: 'host',
+      remotes: {
+        app1: 'app1@http://localhost:3001/remoteEntry.js',
+      },
+    }),
+  ],
+};
+```
+
+But you can also pass a promise as the remote, which is resolved at runtime. You should resolve the promise with anything that fits the `get`/`init` interface described above. For example, if you wanted to choose which version of a federated module to use via a query parameter, you could do something like the following:
+
+```js
+export default {
+  plugins: [
+    new ModuleFederationPlugin({
+      name: 'host',
+      remotes: {
+        app1: `promise new Promise(resolve => {
+      const urlParams = new URLSearchParams(window.location.search)
+      const version = urlParams.get('app1VersionParam')
+      // This part depends on how you plan on hosting and versioning your federated modules
+      const remoteUrlWithVersion = 'http://localhost:3001/' + version + '/remoteEntry.js'
+      const script = document.createElement('script')
+      script.src = remoteUrlWithVersion
+      script.onload = () => {
+        // the injected script has loaded and is available on window
+        // we can now resolve this Promise
+        const proxy = {
+          get: (request) => window.app1.get(request),
+          init: (...arg) => {
+            try {
+              return window.app1.init(...arg)
+            } catch(e) {
+              console.log('remote container already initialized')
+            }
+          }
+        }
+        resolve(proxy)
+      }
+      // inject this script with the src set to the versioned remoteEntry.js
+      document.head.appendChild(script);
+    })
+    `,
+      },
+      // ...
+    }),
+  ],
+};
+```
+
+Note that when you use this API, you _have_ to resolve an object containing the `get`/`init` API.
+
+## Dynamic public path
+
+### Offer a host API to set the public path
+
+You can allow the host to set a remote module's public path at runtime by exposing a method from that remote module.
+
+This approach is especially helpful when you mount independently deployed child applications on a sub-path of the host domain.
+
+Scenario:
+
+You have a host app served at `https://my-host.com/app/*` and a child app served at `https://foo-app.com`. The child app is also mounted on the host domain, so `https://foo-app.com` is expected to be reachable at `https://my-host.com/app/foo-app`, and `https://my-host.com/app/foo-app/*` requests are redirected to `https://foo-app.com/*` via a proxy.
+
+Example:
+
+```js displayName="webpack.config.js (remote)"
+export default {
+  entry: {
+    remote: './public-path',
+  },
+  plugins: [
+    new ModuleFederationPlugin({
+      name: 'remote', // this name needs to match the entry name
+      exposes: ['./public-path'],
+      // ...
+    }),
+  ],
+};
+```
+
+```js displayName="public-path.js (remote)"
+export function set(value) {
+  __webpack_public_path__ = value;
+}
+```
+
+```ts displayName="src/index.js (host)"
+const publicPath = await import('remote/public-path');
+publicPath.set('/your-public-path');
+
+// bootstrap app, e.g. import('./bootstrap.js')
+```
+
+### Infer the public path from the script
+
+You can infer the public path from the script tag via `document.currentScript.src` and set it with the [`__webpack_public_path__`](#TODO[/api/module-variables/#__webpack_public_path__-webpack-specific]) module variable at runtime.
+
+Example:
+
+```js displayName="webpack.config.js (remote)"
+export default {
+  entry: {
+    remote: './setup-public-path',
+  },
+  plugins: [
+    new ModuleFederationPlugin({
+      name: 'remote', // this name needs to match the entry name
+      // ...
+    }),
+  ],
+};
+```
+
+```js displayName="setup-public-path.js (remote)"
+// derive the publicPath with your own logic and set it with the __webpack_public_path__ API
+__webpack_public_path__ = `${document.currentScript.src}/../`;
+```
+
+> [!TIP]
+> There is also an `'auto'` value available for [`output.publicPath`](#TODO[/configuration/output/#outputpublicpath]) that determines the public path for you automatically.
+
+## Troubleshooting
+
+### `Uncaught Error: Shared module is not available for eager consumption`
+
+The application is eagerly executing an application that operates as an omnidirectional host. You have a few options:
+
+You can mark the dependency as eager inside the advanced API of Module Federation. This does not place the modules in an async chunk but provides them synchronously, which lets you use these shared modules in the initial chunk. Be careful, though: all provided and fallback modules are always downloaded. It's recommended to do this at only one point in your application, for example the shell.
+
+We strongly recommend using an asynchronous boundary instead. It splits out the initialization code of a larger chunk to avoid additional round trips and improve overall performance.
+
+For example, suppose your entry looked like this:
+
+```jsx displayName="index.js"
+import { createRoot } from 'react-dom/client';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+root.render(<App />);
+```
+
+Create a `bootstrap.js` file, move the contents of the entry into it, and import that bootstrap from the entry:
+
+```diff displayName="index.js"
++ import('./bootstrap');
+- import { createRoot } from 'react-dom/client';
+- import App from './App';
+
+- const root = createRoot(document.getElementById('root'));
+- root.render(<App />);
+```
+
+```diff displayName="bootstrap.js"
++ import { createRoot } from 'react-dom/client';
++ import App from './App';
++ const root = createRoot(document.getElementById('root'));
++ root.render(<App />);
+```
+
+This method works, but it can have limitations or drawbacks.
+
+Alternatively, set `eager: true` for the dependency via `ModuleFederationPlugin`:
+
+```js displayName="webpack.config.js"
+// ...
+new ModuleFederationPlugin({
+  shared: {
+    ...deps,
+    react: {
+      eager: true,
+    },
+  },
+});
+```
+
+### `Uncaught Error: Module "./Button" does not exist in container.`
+
+The error probably won't say `"./Button"` exactly, but it will look similar. This issue typically appears when you upgrade from webpack beta.16 to webpack beta.17.
+
+Within `ModuleFederationPlugin`, change the `exposes` from:
+
+```diff
+new ModuleFederationPlugin({
+  exposes: {
+-   'Button': './src/Button'
++   './Button':'./src/Button'
+  }
+});
+```
+
+### `Uncaught TypeError: fn is not a function`
+
+You are likely missing the remote container; make sure it's added. If you already have the container loaded for the remote you're trying to consume but still see this error, add the host container's remote container file to the HTML as well.
+
+### Setting `output.uniqueName`
+
+In a Module Federation setup, both the host and every remote must have a globally unique `output.uniqueName`. webpack derives this value from the `name` field in `package.json` by default. This means two builds that share the same `package.json` `name` (a common pattern when splitting a remote out of an existing project) can silently collide at runtime.
+
+One solution is to use a separate `package.json` with a distinct name for each configuration.
+
+Alternatively, set `output.uniqueName` explicitly in each webpack config:
+
+```js displayName="webpack.config.js (host)"
+export default {
+  output: {
+    uniqueName: 'my-host-app',
+  },
+  plugins: [
+    new ModuleFederationPlugin({
+      // ...
+    }),
+  ],
+};
+```
+
+```js displayName="webpack.config.js (remote)"
+export default {
+  output: {
+    uniqueName: 'my-remote-app', // must differ from the host and all other remotes
+  },
+  plugins: [
+    new ModuleFederationPlugin({
+      // ...
+    }),
+  ],
+};
+```
+
+The value can be any string, as long as it is unique across every federated build loaded on a given page.
+
+## Further reading
+
+- [Webpack 5 Module Federation: A game-changer in JavaScript architecture](https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669)
+- [Explanations and Examples](https://github.com/module-federation/module-federation-examples)
+- [Module Federation YouTube Playlist](https://www.youtube.com/playlist?list=PLWSiF9YHHK-DqsFHGYbeAMwbd9xcZbEWJ)
diff --git a/pages/guides/getting-started/concepts/module-resolution.md b/pages/guides/getting-started/concepts/module-resolution.md
new file mode 100644
index 00000000..f80335a7
--- /dev/null
+++ b/pages/guides/getting-started/concepts/module-resolution.md
@@ -0,0 +1,74 @@
+---
+authors: pksjce,pastelsky,byzyk,EugeneHlushko,wizardofhogwarts,avivkeller
+---
+
+# Module Resolution
+
+A resolver is a library that locates a module by its absolute path. When one module depends on another, it requires it like this:
+
+```js
+import foo from 'path/to/module';
+
+// or
+
+require('path/to/module');
+```
+
+The dependency can come from your own application code or from a third-party library. For every such `require`/`import` statement, the resolver tells webpack where to find the module's code so it can be included in the bundle. webpack uses [enhanced-resolve](https://github.com/webpack/enhanced-resolve) to resolve file paths while bundling modules.
+
+## Resolving rules in webpack
+
+With `enhanced-resolve`, webpack can resolve three kinds of file paths.
+
+### Absolute paths
+
+```js
+import '/home/me/file';
+
+import 'C:\\Users\\me\\file';
+```
+
+Since the absolute path to the file is already known, no further resolution is needed.
+
+### Relative paths
+
+```js
+import '../src/file1';
+import './file2';
+```
+
+Here, the directory of the source file containing the `import` or `require` is used as the context directory. The relative path is joined to that context to produce the absolute path of the module.
+
+### Module paths
+
+```js
+import 'my-module';
+import 'my-module/lib/file';
+```
+
+Modules are searched for in every directory listed in [`resolve.modules`](#TODO[/configuration/resolve/#resolvemodules]). You can substitute a different path for the original module path by defining an alias through the [`resolve.alias`](#TODO[/configuration/resolve/#resolvealias]) configuration option.
+
+- If the package contains a `package.json` file, the fields listed in the [`resolve.exportsFields`](#TODO[/configuration/resolve/#resolveexportsfields]) configuration option are checked in order. The first matching field in `package.json` determines the package's available exports, following the [package exports guideline](#TODO[/guides/package-exports/]).
+
+Once the path is resolved by the rules above, the resolver checks whether it points to a file or a directory. If it points to a file:
+
+- If the path already has a file extension, the file is bundled directly.
+- Otherwise, the extension is resolved using the [`resolve.extensions`](#TODO[/configuration/resolve/#resolveextensions]) option, which lists the extensions that are acceptable for resolution, such as `.js` or `.jsx`.
+
+If the path points to a folder, the following steps are taken to find the correct file with the correct extension:
+
+- If the folder contains a `package.json` file, the fields listed in the [`resolve.mainFields`](#TODO[/configuration/resolve/#resolvemainfields]) configuration option are checked in order, and the first matching field in `package.json` determines the file path.
+- If there is no `package.json`, or if [`resolve.mainFields`](#TODO[/configuration/resolve/#resolvemainfields]) does not yield a valid path, the file names listed in the [`resolve.mainFiles`](#TODO[/configuration/resolve/#resolvemainfiles]) option are tried in order to see whether a matching file exists in the imported directory.
+- The file extension is then resolved as before, using the [`resolve.extensions`](#TODO[/configuration/resolve/#resolveextensions]) option.
+
+webpack provides sensible [defaults](#TODO[/configuration/resolve]) for these options based on your build target.
+
+## Resolving loaders
+
+Loader resolution follows the same rules as file resolution. However, the [`resolveLoader`](#TODO[/configuration/resolve/#resolveloader]) configuration option lets you define separate resolution rules specifically for loaders.
+
+## Caching
+
+Every filesystem access is cached, so repeated requests to the same file, whether parallel or serial, resolve faster. In [watch mode](#TODO[/configuration/watch/#watch]), only modified files are evicted from the cache. When watch mode is off, the cache is purged before every compilation.
+
+See the [Resolve API](#TODO[/configuration/resolve]) to learn more about the configuration options mentioned above.
diff --git a/pages/guides/getting-started/concepts/modules.md b/pages/guides/getting-started/concepts/modules.md
new file mode 100644
index 00000000..c4df3b22
--- /dev/null
+++ b/pages/guides/getting-started/concepts/modules.md
@@ -0,0 +1,49 @@
+---
+authors: TheLarkInn,simon04,rouzbeh84,EugeneHlushko,byzyk,avivkeller
+---
+
+# Modules
+
+In [modular programming](https://en.wikipedia.org/wiki/Modular_programming), developers split programs into discrete, self-contained chunks of functionality called _modules_.
+
+Each module covers a smaller surface area than the program as a whole, which makes verification, debugging, and testing far simpler. Well-written modules offer solid abstractions and clear encapsulation boundaries, so every module has a coherent design and a clear purpose within the larger application.
+
+Node.js has supported modular programming almost since its inception. On the web, however, support for modules was slow to arrive. A number of tools sprang up to bring modular JavaScript to the browser, each with its own benefits and limitations. webpack builds on the lessons learned from those systems and applies the concept of modules to any file in your project.
+
+## What is a webpack module
+
+Unlike [Node.js modules](https://nodejs.org/api/modules.html), webpack modules can express their dependencies in several different ways. A few examples:
+
+- An [ES2015 `import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) statement
+- A [CommonJS](https://wiki.commonjs.org/wiki/Modules/1.1) `require()` statement
+- An [AMD](https://github.com/amdjs/amdjs-api/blob/master/AMD.md) `define` and `require` statement
+- An [`@import` statement](https://developer.mozilla.org/en-US/docs/Web/CSS/@import) inside a CSS, Sass, or Less file
+- An image URL in a stylesheet (`url(...)`) or in an HTML `<img src=...>` element
+
+## Supported module types
+
+webpack supports the following module types natively:
+
+- [ECMAScript modules](#TODO[/guides/ecma-script-modules])
+- CommonJS modules
+- AMD modules
+- [Assets](#TODO[/guides/asset-modules])
+- WebAssembly modules
+
+Beyond these, webpack supports modules written in many other languages and preprocessors through _loaders_. Loaders tell webpack **how** to process non-native modules and how to include their dependencies in your bundles. The webpack community has built loaders for a wide range of popular languages and language processors, including:
+
+- [CoffeeScript](http://coffeescript.org)
+- [TypeScript](https://www.typescriptlang.org)
+- [ESNext (Babel)](https://babeljs.io)
+- [Sass](http://sass-lang.com)
+- [Less](http://lesscss.org)
+- [Stylus](http://stylus-lang.com)
+- [Elm](https://elm-lang.org/)
+
+And many more. In short, webpack offers a powerful, rich API for customization that lets you use it with **any stack** while remaining **non-opinionated** about your development, testing, and production workflows.
+
+For a complete list, see [the list of loaders](#TODO[/loaders]) or learn how to [write your own](#TODO[/api/loaders]).
+
+## Further reading
+
+- [JavaScript Module Systems Showdown](https://auth0.com/blog/javascript-module-systems-showdown/)
diff --git a/pages/guides/getting-started/concepts/output.md b/pages/guides/getting-started/concepts/output.md
new file mode 100644
index 00000000..91cdd5ec
--- /dev/null
+++ b/pages/guides/getting-started/concepts/output.md
@@ -0,0 +1,68 @@
+---
+authors: TheLarkInn,chyipin,rouzbeh84,byzyk,EugeneHlushko,avivkeller
+---
+
+# Output
+
+The `output` configuration options tell webpack how to write the compiled files to disk. Note that while a configuration can have multiple `entry` points, it can specify only one `output`.
+
+## Usage
+
+The minimum requirement for the `output` property is to set it to an object and provide an [`output.filename`](#TODO[/configuration/output/#outputfilename]) for the output file(s):
+
+```js displayName="webpack.config.js"
+export default {
+  output: {
+    filename: 'bundle.js',
+  },
+};
+```
+
+This configuration writes a single `bundle.js` file into the `dist` directory.
+
+## Multiple entry points
+
+If your configuration produces more than one "chunk", as happens with multiple entry points or with plugins like `CommonsChunkPlugin`, use [substitutions](#TODO[/configuration/output/#outputfilename]) to give each file a unique name:
+
+```js
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: {
+    app: './src/app.js',
+    search: './src/search.js',
+  },
+  output: {
+    filename: '[name].js',
+    path: path.resolve(__dirname, './dist'),
+  },
+};
+
+// writes to disk: ./dist/app.js, ./dist/search.js
+```
+
+## Advanced
+
+Here is a more involved example that uses a CDN together with hashes for assets:
+
+```js displayName="config.js"
+export default {
+  // ...
+  output: {
+    path: '/home/proj/cdn/assets/[fullhash]',
+    publicPath: 'https://cdn.example.com/assets/[fullhash]/',
+  },
+};
+```
+
+When the eventual `publicPath` of the output files is not known at compile time, you can leave it blank and set it dynamically at runtime through the `__webpack_public_path__` variable in your entry point file:
+
+```js
+__webpack_public_path__ = myRuntimePublicPath;
+
+// rest of your application entry
+```
diff --git a/pages/guides/getting-started/concepts/plugins.md b/pages/guides/getting-started/concepts/plugins.md
new file mode 100644
index 00000000..653121bf
--- /dev/null
+++ b/pages/guides/getting-started/concepts/plugins.md
@@ -0,0 +1,90 @@
+---
+authors: TheLarkInn,jhnns,rouzbeh84,johnstew,MisterDev,byzyk,chenxsan,avivkeller
+---
+
+# Plugins
+
+Plugins are the [backbone](https://github.com/webpack/tapable) of webpack. webpack itself is built on the **same plugin system** that you use in your own configuration.
+
+Plugins also handle **anything else** that a [loader](#TODO[/concepts/loaders]) cannot do. webpack ships with [many plugins](#TODO[/plugins/]) out of the box.
+
+> [!TIP]
+> When consuming the [`webpack-sources`](https://github.com/webpack/webpack-sources) package in plugins, prefer `compiler.webpack.sources` over importing from `webpack` or `webpack-sources` directly. This avoids version conflicts with persistent caching.
+
+## Anatomy
+
+A webpack plugin is a JavaScript object with an [`apply`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply) method. The webpack compiler calls this `apply` method, giving the plugin access to the **entire** compilation lifecycle.
+
+```js displayName="ConsoleLogOnBuildWebpackPlugin.js"
+const pluginName = 'ConsoleLogOnBuildWebpackPlugin';
+
+class ConsoleLogOnBuildWebpackPlugin {
+  apply(compiler) {
+    compiler.hooks.run.tap(pluginName, compilation => {
+      console.log('The webpack build process is starting!');
+    });
+  }
+}
+
+export default ConsoleLogOnBuildWebpackPlugin;
+```
+
+The first argument to the compiler hook's `tap` method should be a camelized version of the plugin name. Defining it as a constant is recommended so it can be reused across all hooks.
+
+## Usage
+
+Because plugins can take arguments and options, you pass a `new` instance to the `plugins` property in your webpack configuration. Depending on how you use webpack, there are several ways to add plugins.
+
+### Configuration
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import HtmlWebpackPlugin from 'html-webpack-plugin';
+import webpack from 'webpack'; // to access built-in plugins
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './path/to/my/entry/file.js',
+  output: {
+    filename: 'my-first-webpack.bundle.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+  module: {
+    rules: [
+      {
+        test: /\.(js|jsx)$/,
+        use: 'babel-loader',
+      },
+    ],
+  },
+  plugins: [
+    new webpack.ProgressPlugin(),
+    new HtmlWebpackPlugin({ template: './src/index.html' }),
+  ],
+};
+```
+
+`ProgressPlugin` customizes how progress is reported during compilation, and `HtmlWebpackPlugin` generates an HTML file that includes `my-first-webpack.bundle.js` via a `script` tag.
+
+### Node API
+
+When using the Node API, you can also pass plugins through the `plugins` property in the configuration.
+
+```js displayName="some-node-script.js"
+import webpack from 'webpack'; // to access webpack runtime
+import configuration from './webpack.config.js';
+
+const compiler = webpack(configuration);
+
+new webpack.ProgressPlugin().apply(compiler);
+
+compiler.run((err, stats) => {
+  // ...
+});
+```
+
+> [!TIP]
+> The example above is remarkably similar to the [webpack runtime itself](https://github.com/webpack/webpack/blob/e7087ffeda7fa37dfe2ca70b5593c6e899629a2c/bin/webpack.js#L290-L292). The [webpack source code](https://github.com/webpack/webpack) hides plenty of great usage examples that you can apply to your own configurations and scripts.
diff --git a/pages/guides/getting-started/concepts/targets.md b/pages/guides/getting-started/concepts/targets.md
new file mode 100644
index 00000000..153a4bde
--- /dev/null
+++ b/pages/guides/getting-started/concepts/targets.md
@@ -0,0 +1,79 @@
+---
+authors: TheLarkInn,rouzbeh84,johnstew,srilman,byzyk,EugeneHlushko,avivkeller
+---
+
+# Targets
+
+Because JavaScript can run on both the server and the browser, webpack offers several deployment _targets_ that you can set in your webpack [configuration](#TODO[/configuration]).
+
+> [!WARNING]
+> Do not confuse the webpack `target` property with the `output.libraryTarget` property. For more information, see our [guide](#TODO[/concepts/output/]) on the `output` property.
+
+## Usage
+
+To set the `target` property, assign the target value in your webpack config:
+
+```js displayName="webpack.config.js"
+export default {
+  target: 'node',
+};
+```
+
+In the example above, `node` tells webpack to compile for a Node.js-like environment: chunks are loaded with Node.js's `require`, and built-in modules such as `fs` and `path` are left untouched.
+
+Each target comes with deployment- and environment-specific additions tailored to its needs. See which [targets are available](#TODO[/configuration/target/]).
+
+> [!NOTE]
+> Further expansion for other popular target values.
+
+## Multiple targets
+
+webpack lets you pass an [array of strings](#TODO[/configuration/target/#string]) to the `target` property, in which case the common subset of those targets' features is used. This lets you build universal code that runs in multiple environments. For example, you can combine `web` and `node`:
+
+```js displayName="webpack.config.js"
+export default {
+  target: ['web', 'node'],
+};
+```
+
+Alternatively, you can build an isomorphic library by bundling two separate configurations:
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+const serverConfig = {
+  target: 'node',
+  output: {
+    path: path.resolve(__dirname, 'dist'),
+    filename: 'lib.node.js',
+  },
+  // …
+};
+
+const clientConfig = {
+  target: 'web', // <=== can be omitted as 'web' is the default
+  output: {
+    path: path.resolve(__dirname, 'dist'),
+    filename: 'lib.js',
+  },
+  // …
+};
+
+export default [serverConfig, clientConfig];
+```
+
+This example creates a `lib.js` file and a `lib.node.js` file in your `dist` folder.
+
+## Resources
+
+As the options above show, you can choose from multiple deployment _targets_. Below is a list of examples and resources you can refer to.
+
+- **[compare-webpack-target-bundles](https://github.com/TheLarkInn/compare-webpack-target-bundles)**: A great resource for testing and inspecting different webpack _targets_, and useful for bug reporting.
+- **[Boilerplate of Electron-React Application](https://github.com/chentsulin/electron-react-boilerplate)**: A good example of a build process for Electron's main and renderer processes.
+
+> [!NOTE]
+> Need to find up-to-date examples of these webpack targets being used in live code or boilerplates.
diff --git a/pages/guides/getting-started/concepts/under-the-hood.md b/pages/guides/getting-started/concepts/under-the-hood.md
new file mode 100644
index 00000000..d490ffaa
--- /dev/null
+++ b/pages/guides/getting-started/concepts/under-the-hood.md
@@ -0,0 +1,122 @@
+---
+authors: smelukov,EugeneHlushko,chenxsan,amirsaeed671,avivkeller
+---
+
+# Under the Hood
+
+> [!NOTE]
+> This section describes webpack internals and is useful primarily for plugin developers.
+
+At its core, bundling is a function that takes some files and emits others.
+
+Between input and output, however, it works with [modules](#TODO[/concepts/modules/]), [entry points](#TODO[/concepts/entry-points/]), chunks, chunk groups, and many other intermediate pieces.
+
+## The main parts
+
+Every file used in your project is a [module](#TODO[/concepts/modules/]).
+
+```js displayName="./index.js"
+import app from './app.js';
+```
+
+```js displayName="./app.js"
+export default 'the app';
+```
+
+By referencing one another, the modules form a graph (`ModuleGraph`).
+
+During bundling, modules are combined into chunks. Chunks combine into chunk groups and form a graph (`ChunkGraph`) interconnected through modules. When you describe an entry point, webpack creates a chunk group with one chunk under the hood.
+
+```js displayName="./webpack.config.js"
+export default {
+  entry: './index.js',
+};
+```
+
+This creates one chunk group named `main` (`main` is the default name for an entry point). The chunk group contains the `./index.js` module, and as the parser handles the imports inside `./index.js`, new modules are added to this chunk.
+
+Another example:
+
+```js displayName="./webpack.config.js"
+export default {
+  entry: {
+    home: './home.js',
+    about: './about.js',
+  },
+};
+```
+
+This creates two chunk groups, named `home` and `about`. Each has one chunk containing a single module: `./home.js` for `home` and `./about.js` for `about`.
+
+> [!NOTE]
+> A chunk group may contain more than one chunk. For example, [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) splits a chunk into one or more chunks.
+
+## Chunks
+
+Chunks come in two forms:
+
+- `initial` is the main chunk for an entry point. It contains all the modules and their dependencies that you specify for that entry point.
+- `non-initial` is a chunk that may be lazy-loaded. It can appear when a [dynamic import](#TODO[/guides/code-splitting/#dynamic-imports]) or [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is used.
+
+Each chunk has a corresponding **asset**. Assets are the output files, the result of bundling.
+
+```js displayName="webpack.config.js"
+export default {
+  entry: './src/index.jsx',
+};
+```
+
+```jsx displayName="./src/index.jsx"
+import { createRoot } from 'react-dom/client';
+
+import('./app.jsx').then(App => {
+  const root = createRoot(document.getElementById('root'));
+  root.render(<App />);
+});
+```
+
+An initial chunk named `main` is created. It contains:
+
+- `./src/index.jsx`
+- `react`
+- `react-dom`
+
+along with all of their dependencies, except `./app.jsx`.
+
+A non-initial chunk for `./app.jsx` is created because that module is imported dynamically.
+
+**Output:**
+
+- `/dist/main.js` — an `initial` chunk
+- `/dist/394.js` — a `non-initial` chunk
+
+By default, `non-initial` chunks have no name, so a unique ID is used instead. When using a dynamic import, you can specify a chunk name explicitly with a ["magic" comment](#TODO[/api/module-methods/#magic-comments]):
+
+```jsx
+import(
+  /* webpackChunkName: "app" */
+  './app.jsx'
+).then(App => {
+  const root = createRoot(document.getElementById('root'));
+  root.render(<App />);
+});
+```
+
+**Output:**
+
+- `/dist/main.js` — an `initial` chunk
+- `/dist/app.js` — a `non-initial` chunk
+
+## Output
+
+The names of the output files are controlled by two fields in the config:
+
+- [`output.filename`](#TODO[/configuration/output/#outputfilename]) — for `initial` chunk files
+- [`output.chunkFilename`](#TODO[/configuration/output/#outputchunkfilename]) — for `non-initial` chunk files
+- In some cases a chunk is used as both `initial` and `non-initial`. In those cases, `output.filename` is used.
+
+A [few placeholders](#TODO[/configuration/output/#template-strings]) are available in these fields. The most common are:
+
+- `[id]` — the chunk id (e.g. `[id].js` → `485.js`)
+- `[name]` — the chunk name (e.g. `[name].js` → `app.js`); if a chunk has no name, its id is used instead
+- `[contenthash]` — an md4 hash of the output file's content (e.g. `[contenthash].js` → `4ea6ff1de66c537eb9b2.js`)
diff --git a/pages/guides/getting-started/concepts/why-webpack.md b/pages/guides/getting-started/concepts/why-webpack.md
new file mode 100644
index 00000000..ff5ff6ba
--- /dev/null
+++ b/pages/guides/getting-started/concepts/why-webpack.md
@@ -0,0 +1,47 @@
+---
+authors: debs-obrien,montogeek,jeremenichelli,EugeneHlushko,avivkeller
+---
+
+# Why webpack
+
+To understand why you should use webpack, let's revisit how JavaScript was used on the web before bundlers existed.
+
+There are two ways to run JavaScript in a browser. The first is to include a separate script for each piece of functionality, but this approach is hard to scale because loading too many scripts can create a network bottleneck. The second is to put all of your project's code in one large `.js` file, but that introduces problems with scope, file size, readability, and maintainability.
+
+## IIFEs — immediately invoked function expressions
+
+IIFEs solve scoping problems in large projects. When script files are wrapped in an IIFE, you can safely concatenate or combine them without worrying about scope collisions.
+
+This pattern led to tools like Make, Gulp, Grunt, Broccoli, and Brunch. Known as task runners, they concatenate all of your project files together.
+
+However, changing a single file means rebuilding the whole thing. Concatenation makes it easier to reuse scripts across files, but it also makes build optimizations harder. How do you find out whether a piece of code is actually being used? Even if you use only one function from Lodash, you have to ship the entire library and then minify it all together. How do you tree-shake your dependencies? Lazy-loading chunks of code at scale is difficult and requires a great deal of manual effort.
+
+## The birth of JavaScript modules, thanks to Node.js
+
+webpack runs on Node.js, a JavaScript runtime that runs on computers and servers outside the browser.
+
+The release of Node.js started a new era, and it brought new challenges. Now that JavaScript was no longer confined to the browser, how were Node applications supposed to load new chunks of code? There were no HTML files or script tags to add them to.
+
+CommonJS arrived and introduced `require`, which lets you load and use a module in the current file. This solved scope issues out of the box by importing each module as it was needed.
+
+## npm + Node.js + modules — mass distribution
+
+JavaScript was taking over the world as a language, as a platform, and as a way to rapidly build fast applications.
+
+But browsers had no support for CommonJS. There were no [live bindings](https://medium.com/webpack/the-state-of-javascript-modules-4636d1774358), there were problems with circular references, and synchronous module resolution and loading was slow. While CommonJS was a great solution for Node.js projects, browsers did not support modules, so bundlers and tools like Browserify, RequireJS, and SystemJS were created to let us write CommonJS modules that run in a browser.
+
+## ESM — ECMAScript modules
+
+The good news for web projects is that modules are becoming an official feature of the ECMAScript standard. However, browser support is still incomplete, and bundling remains faster and is currently recommended over these early module implementations.
+
+## Automatic dependency collection
+
+Old-school task runners, and even the Google Closure Compiler, require you to declare all dependencies manually and upfront. Bundlers like webpack, by contrast, automatically build and infer your [dependency graph](#TODO[/concepts/dependency-graph/]) from what you import and export. Together with [plugins](#TODO[/concepts/plugins/]) and [loaders](#TODO[/concepts/loaders/]), this makes for a great developer experience.
+
+## Wouldn't it be nice…
+
+…to have something that not only lets us write modules but also supports any module format (at least until everyone is on ESM) and handles resources and assets at the same time?
+
+That is why webpack exists. It is a tool that bundles your JavaScript applications, supporting both ESM and CommonJS, and it can be extended to handle many other assets such as images, fonts, and stylesheets.
+
+webpack cares about performance and load times. It is always improving and adding new features, such as async chunk loading and prefetching, to deliver the best possible experience for your project and your users.
diff --git a/pages/guides/getting-started/index.md b/pages/guides/getting-started/index.md
new file mode 100644
index 00000000..ba44b747
--- /dev/null
+++ b/pages/guides/getting-started/index.md
@@ -0,0 +1,393 @@
+---
+authors: bebraw,varunjayaraman,cntanglijun,chrisVillanueva,johnstew,simon04,aaronang,TheDutchCoder,sudarsangp,Vanguard90,chenxsan,EugeneHlushko,ATGardner,ayvarot,bjarki,ztomasze,Spiral90210,byzyk,wizardofhogwarts,myshov,anshumanv,d3lm,snitin315,Etheryen,zowiebeha,avivkeller
+---
+
+# Getting Started
+
+webpack is a good fit when your application needs a customizable build pipeline: bundling JavaScript modules, processing assets, integrating loaders and plugins, and shaping output for different environments. For a very small page with one or two scripts, a bundler may be unnecessary at first; but for an application with shared dependencies, npm packages, assets, and production builds, webpack gives you explicit control over how everything is assembled.
+
+webpack is used to efficiently compile JavaScript modules. Once [installed](#TODO[/guides/installation]), you can interact with webpack through either its [CLI](#TODO[/api/cli]) or its [API](#TODO[/api/node]). If you're new to webpack, please read through the [core concepts](#TODO[/concepts]) and [this comparison](#TODO[/comparison]) to learn why you might choose it over the other tools available in the community.
+
+> [!WARNING]
+> The examples in this guide use `webpack-cli` 7, which requires Node.js 20.9.0 or later.
+
+<!-- TODO: StackBlitzPreview example="getting-started?terminal=" -->
+
+## Quick start (minimal working example)
+
+If you want to get a working webpack project up and running quickly, the easiest way is to scaffold one with `create-webpack-app`.
+
+```bash
+npx create-webpack-app webpack-demo
+cd webpack-demo
+```
+
+> [!TIP]
+> Need a CLI-based project setup or templates? See the [Init command](#TODO[/api/cli/#init]) for webpack's scaffolding flow.
+
+> [!TIP]
+> This command generates a ready-to-use webpack project with a sensible default configuration. Continue below if you'd like to understand how to set up webpack manually, step by step.
+
+## Basic setup
+
+First, let's create a directory, initialize npm, [install webpack locally](#TODO[/guides/installation/#local-installation]), and install the [`webpack-cli`](https://github.com/webpack/webpack-cli) (the tool used to run webpack on the command line):
+
+```bash
+# Run the commands for one package manager only.
+
+mkdir webpack-demo
+cd webpack-demo
+
+# npm
+npm init -y
+npm install webpack webpack-cli --save-dev
+
+# yarn
+yarn init -y
+yarn add webpack webpack-cli --dev
+
+# pnpm
+pnpm init
+pnpm add webpack webpack-cli -D
+```
+
+Throughout these guides, we use **`diff`** blocks to show you what changes we're making to directories, files, and code. For instance:
+
+```diff
++ this is a new line you shall copy into your code
+- and this is a line to be removed from your code
+  and this is a line not to touch.
+```
+
+Now we'll create the following directory structure, files, and contents:
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── package-lock.json
++ ├── index.html
++ └── src/
++    └── index.js
+```
+
+```js displayName="src/index.js"
+function component() {
+  const element = document.createElement('div');
+
+  // Lodash, currently included via a script, is required for this line to work
+  element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+  return element;
+}
+
+document.body.appendChild(component());
+```
+
+```html displayName="index.html"
+<!DOCTYPE html>
+<html>
+  <head>
+    <meta charset="utf-8" />
+    <title>Getting Started</title>
+    <script src="https://unpkg.com/lodash@4.17.21"></script>
+  </head>
+  <body>
+    <script src="./src/index.js"></script>
+  </body>
+</html>
+```
+
+We also need to adjust our `package.json` file to mark the package as `private` and remove the `main` entry. This prevents an accidental publish of your code.
+
+We also add `"type": "module"` so that Node.js treats `.js` files in this project as ES modules. That setting applies project-wide, including future Node.js scripts and webpack configuration files. If you'd rather keep Node's default CommonJS behavior, omit `"type": "module"` and write the configuration later in this guide with `require(...)` and `module.exports` instead of `import` and `export default`.
+
+> [!TIP]
+> If you want to learn more about the inner workings of `package.json`, we recommend reading the [npm documentation](https://docs.npmjs.com/files/package.json).
+
+```diff displayName="package.json"
+ {
+   "name": "webpack-demo",
+   "version": "1.0.0",
+   "description": "",
+-  "main": "index.js",
++  "private": true,
++  "type": "module",
+   "scripts": {
+     "test": "echo \"Error: no test specified\" && exit 1"
+   },
+   "keywords": [],
+   "author": "",
+   "license": "MIT",
+   "devDependencies": {
+     "webpack": "^5.105.0",
+     "webpack-cli": "^7.0.0"
+   }
+ }
+```
+
+In this example, there are implicit dependencies between the `<script>` tags. Our `index.js` file depends on `lodash` being included in the page before it runs. This creates an implicit dependency on a global variable (`_`), making script execution order critical and harder to maintain.
+
+Managing JavaScript projects this way has several problems:
+
+- It is not immediately apparent that the script depends on an external library.
+- If a dependency is missing or included in the wrong order, the application will not function properly.
+- If a dependency is included but not used, the browser is forced to download unnecessary code.
+
+webpack solves these issues by explicitly declaring dependencies and bundling them together. This removes reliance on global variables and ensures scripts execute in the correct order.
+
+## Creating a bundle
+
+First, we'll tweak our directory structure slightly, separating the "source" code (`./src`) from the "distribution" code (`./dist`). The source code is what we write and edit. The distribution code is the minimized, optimized `output` of our build process that will eventually be loaded in the browser. Tweak the directory structure as follows:
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
++  ├── /dist
++  │   └── index.html
+-  ├── index.html
+   └── /src
+       └── index.js
+```
+
+The `dist` directory is build output, so in a mature project you usually do not hand-edit files there. We are moving `index.html` into `dist` for now only as temporary scaffolding, so the browser has an HTML file that loads the first generated bundle. Later, in [another guide](#TODO[/guides/output-management/#setting-up-htmlwebpackplugin]), we'll generate `index.html` rather than edit it manually. Once that's done, it should be safe to empty the `dist` directory and regenerate all the files within it.
+
+To bundle the `lodash` dependency with `index.js`, we'll need to install the library locally:
+
+```bash
+# Run the command for one package manager only.
+
+# npm
+npm install lodash
+
+# yarn
+yarn add lodash
+
+# pnpm
+pnpm add lodash
+```
+
+> [!TIP]
+> With npm 5 and later, packages installed with `npm install <package>` are saved to `dependencies` by default. If you're installing a package for development purposes (such as a linter or testing library), use `npm install --save-dev`. More information can be found in the [npm documentation](https://docs.npmjs.com/cli/install).
+
+Now let's import `lodash` in our script:
+
+```diff displayName="src/index.js"
++import _ from 'lodash';
++
+ function component() {
+   const element = document.createElement('div');
+
+-  // Lodash, currently included via a script, is required for this line to work
++  // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+Since we'll be bundling our scripts, we now have to update our `index.html` file. Let's remove the lodash `<script>`, since we now `import` it, and modify the other `<script>` tag to load the bundle instead of the raw `./src` file:
+
+```diff displayName="dist/index.html"
+ <!DOCTYPE html>
+ <html>
+   <head>
+     <meta charset="utf-8" />
+     <title>Getting Started</title>
+-    <script src="https://unpkg.com/lodash@4.17.21"></script>
+   </head>
+   <body>
+-    <script src="./src/index.js"></script>
++    <script src="main.js"></script>
+   </body>
+ </html>
+```
+
+In this setup, `index.js` explicitly requires `lodash` to be present and binds it as `_` (with no global scope pollution). By declaring what dependencies a module needs, webpack can use that information to build a dependency graph. It then uses the graph to generate an optimized bundle in which scripts execute in the correct order.
+
+> [!TIP]
+> A couple of other script-loading strategies exist. Deferred loading is one alternative to the above: scripts are consolidated into the `<head>` and given the `defer` attribute. This strategy downloads external script resources in parallel with document parsing and executes the scripts in order of document appearance after parsing has finished. This contrasts with the approach above, in which the parser pauses to download and then execute the external resource synchronously. To learn more, MDN has a nice [reference guide](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script#async_and_defer).
+
+With that said, let's run `npx webpack` from the project root. If webpack is installed locally, `npx` runs the local binary from `node_modules/.bin`; otherwise, it may download and execute it. This command takes our script at `src/index.js` as the [entry point](#TODO[/concepts/entry-points]) and generates `dist/main.js` as the [output](#TODO[/concepts/output]).
+
+```bash
+# Run the command for one package manager only.
+
+# npm
+npx webpack
+
+# yarn
+yarn webpack
+
+# pnpm
+pnpm exec webpack
+
+[webpack-cli] Compilation finished
+asset main.js 69.3 KiB [emitted] [minimized] (name: main) 1 related asset
+runtime modules 1000 bytes 5 modules
+cacheable modules 530 KiB
+  ./src/index.js 257 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 1851 ms
+```
+
+> [!TIP]
+> Your output may vary a bit, but if the build is successful then you're good to go.
+
+> [!TIP]
+> webpack runs in production mode by default when no mode is set, so the output above includes `[minimized]` and the generated `dist/main.js` is optimized for browsers rather than for easy reading. While learning, you can run `npx webpack --mode development`, `yarn webpack --mode development`, or `pnpm exec webpack --mode development` to produce a more readable bundle.
+
+Open `index.html` from the `dist` directory in your browser, and if everything went right, you should see the text `'Hello webpack'`.
+
+## Modules
+
+The [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) statements were standardized in [ES2015](https://babeljs.io/docs/en/learn/). They are supported in most browsers today, though some browsers don't recognize the new syntax. Don't worry, though: webpack supports them out of the box.
+
+Behind the scenes, webpack analyzes your module graph and bundles the modules into code the browser can load in the right order. It handles module syntax such as `import` and `export`, and supports various other module syntaxes as well. See [Module API](#TODO[/api/module-methods]) for more information.
+
+Note that webpack will not alter any code other than `import` and `export` statements. If you're using other [ES2015 features](http://es6-features.org/), make sure to [use a transpiler](#TODO[/loaders/#transpiling]) such as [Babel](https://babeljs.io/) via webpack's [loader system](#TODO[/concepts/loaders/]).
+
+## Using a configuration
+
+As of version 4, webpack doesn't require any configuration, but most projects will need a more complex setup, which is why webpack supports a [configuration file](#TODO[/concepts/configuration]). This is much more efficient than manually typing a lot of commands in the terminal, so let's create one.
+
+webpack configuration files can be written using either CommonJS or ECMAScript modules. The examples below use modern ESM syntax.
+
+```diff displayName="project"
+  webpack-demo
+   ├── package.json
+   ├── package-lock.json
++  ├── webpack.config.js
+   ├── /dist
+   │   └── index.html
+   └── /src
+       └── index.js
+```
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+// In Node.js versions prior to native support for import.meta.dirname,
+// derive __dirname from import.meta.url.
+// (Node 20.11+ supports import.meta.dirname and import.meta.filename.)
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'main.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+};
+```
+
+Now let's run the build again, but using our new configuration file this time:
+
+```bash
+# Run the command for one package manager only.
+
+# npm
+npx webpack --config webpack.config.js
+
+# yarn
+yarn webpack --config webpack.config.js
+
+# pnpm
+pnpm exec webpack --config webpack.config.js
+
+[webpack-cli] Compilation finished
+asset main.js 69.3 KiB [compared for emit] [minimized] (name: main) 1 related asset
+runtime modules 1000 bytes 5 modules
+cacheable modules 530 KiB
+  ./src/index.js 257 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 1934 ms
+```
+
+> [!TIP]
+> If a `webpack.config.js` is present, the `webpack` command picks it up by default. We use the `--config` option here only to show that you can pass a configuration of any name. This is useful for more complex configurations that need to be split into multiple files.
+
+A configuration file offers far more flexibility than CLI usage. We can specify loader rules, plugins, resolve options, and many other enhancements this way. See the [configuration documentation](#TODO[/configuration]) to learn more.
+
+## npm scripts
+
+Since running a local copy of webpack from the CLI isn't particularly fun, we can set up a little shortcut. Let's adjust our `package.json` by adding an [npm script](https://docs.npmjs.com/misc/scripts):
+
+```diff displayName="package.json"
+ {
+   "name": "webpack-demo",
+   "version": "1.0.0",
+   "description": "",
+   "private": true,
+   "scripts": {
+-    "test": "echo \"Error: no test specified\" && exit 1"
++    "test": "echo \"Error: no test specified\" && exit 1",
++    "build": "webpack"
+   },
+   "keywords": [],
+   "author": "",
+   "license": "ISC",
+   "devDependencies": {
+     "webpack": "^5.105.0",
+     "webpack-cli": "^7.0.0"
+   },
+   "dependencies": {
+     "lodash": "^4.17.21"
+   }
+ }
+```
+
+Now the `npm run build` command can be used in place of the `npx` command we used earlier. Note that within `scripts` we can reference locally installed npm packages by name, just as we did with `npx`. This convention is standard in most npm-based projects because it lets all contributors use the same set of common scripts.
+
+Now run the following command and see if your script alias works:
+
+```bash
+# Run the command for one package manager only.
+
+# npm
+npm run build
+
+# yarn
+yarn build
+
+# pnpm
+pnpm run build
+...
+
+[webpack-cli] Compilation finished
+asset main.js 69.3 KiB [compared for emit] [minimized] (name: main) 1 related asset
+runtime modules 1000 bytes 5 modules
+cacheable modules 530 KiB
+  ./src/index.js 257 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 1940 ms
+```
+
+> [!TIP]
+> Custom parameters can be passed to webpack by adding two dashes between the `npm run build` command and your parameters, e.g. `npm run build -- --color`.
+
+## Conclusion
+
+Now that you have a basic build together, you should move on to the next guide, [Asset Management](#TODO[/guides/asset-management]), to learn how to manage assets such as images and fonts with webpack. At this point, your project should look like this:
+
+```diff displayName="project"
+webpack-demo
+ ├── package.json
+ ├── package-lock.json
+ ├── webpack.config.js
+ ├── /dist
+ │   ├── main.js
+ │   └── index.html
+ ├── /src
+ │   └── index.js
+ └── /node_modules
+```
+
+> [!WARNING]
+> Do not compile untrusted code with webpack. It could lead to execution of malicious code on your computer, on remote servers, or in the web browsers of your application's end users.
+
+If you want to learn more about webpack's design, you can check out the [basic concepts](#TODO[/concepts]) and [configuration](#TODO[/configuration]) pages. Furthermore, the [API](#TODO[/api]) section digs into the various interfaces webpack offers.
diff --git a/pages/guides/getting-started/installing-webpack.md b/pages/guides/getting-started/installing-webpack.md
new file mode 100644
index 00000000..e5cd4616
--- /dev/null
+++ b/pages/guides/getting-started/installing-webpack.md
@@ -0,0 +1,69 @@
+---
+authors: pksjce,bebraw,simon04,EugeneHlushko,sibiraj-s,chenxsan,avivkeller
+---
+
+# Installation
+
+This guide covers the various methods used to install webpack.
+
+## Prerequisites
+
+Before you begin, make sure you have a recent version of [Node.js](https://nodejs.org/en/) installed. The current Long Term Support (LTS) release is an ideal starting point. Older versions may cause a variety of issues, since they can lack functionality that webpack and its related packages depend on.
+
+## Local installation
+
+The latest webpack release is:
+
+[![GitHub release](https://img.shields.io/npm/v/webpack.svg?label=webpack&style=flat-square&maxAge=3600)](https://github.com/webpack/webpack/releases)
+
+To install the latest release or a specific version, run one of the following commands:
+
+```bash
+npm install --save-dev webpack
+# or a specific version
+npm install --save-dev webpack@<version>
+```
+
+> [!TIP]
+> Whether to use `--save-dev` depends on your use case. If you use webpack only for bundling, installing it with `--save-dev` is recommended, since you won't include webpack in your production build. Otherwise, you can omit `--save-dev`.
+
+If you're using webpack v4 or later and want to call `webpack` from the command line, you'll also need to install the [CLI](#TODO[/api/cli/]):
+
+```bash
+npm install --save-dev webpack-cli
+```
+
+Installing locally is what we recommend for most projects. It makes it easier to upgrade projects individually when breaking changes are introduced. Typically, webpack is run through one or more [npm scripts](https://docs.npmjs.com/misc/scripts) that look for a webpack installation in your local `node_modules` directory:
+
+```json
+"scripts": {
+  "build": "webpack --config webpack.config.js"
+}
+```
+
+> [!TIP]
+> To run a local installation of webpack, you can access its binary at `node_modules/.bin/webpack`. Alternatively, if you are using npm v5.2.0 or greater, you can run `npx webpack`.
+
+## Global installation
+
+The following npm installation makes `webpack` available globally:
+
+```bash
+npm install --global webpack
+```
+
+> [!WARNING]
+> This is **not a recommended practice**. Installing globally locks you into a specific version of webpack and may fail in projects that use a different version.
+
+## Bleeding edge
+
+If you're eager to use the latest features webpack has to offer, you can install beta versions or even install directly from the webpack repository with the following commands:
+
+```bash
+npm install --save-dev webpack@next
+# or a specific tag/branch
+npm install --save-dev webpack/webpack#<tagname/branchname>
+```
+
+> [!WARNING]
+> Take caution when installing these bleeding edge releases. They may still contain bugs and therefore should not be used in production.
diff --git a/pages/guides/index.md b/pages/guides/index.md
new file mode 100644
index 00000000..fa00b75d
--- /dev/null
+++ b/pages/guides/index.md
@@ -0,0 +1,3 @@
+# STUB
+
+STUB
diff --git a/pages/guides/migration/index.md b/pages/guides/migration/index.md
new file mode 100644
index 00000000..f7dc1235
--- /dev/null
+++ b/pages/guides/migration/index.md
@@ -0,0 +1,7 @@
+---
+authors: EugeneHlushko,avivkeller
+---
+
+# Migrate
+
+This section covers how to migrate from older versions of webpack to newer ones.
diff --git a/pages/guides/migration/to-v3.md b/pages/guides/migration/to-v3.md
new file mode 100644
index 00000000..758536f9
--- /dev/null
+++ b/pages/guides/migration/to-v3.md
@@ -0,0 +1,589 @@
+---
+authors: sokra,jhnns,grgur,domfarolino,johnnyreilly,jouni-kantola,frederikprijck,chrisVillanueva,bebraw,howdy39,selbekk,ndelangen,EugeneHlushko,byzyk,avivkeller
+---
+
+# To v2 or v3 from v1
+
+The sections below walk through the major changes between webpack 1 and webpack 2.
+
+> [!TIP]
+> Far fewer things changed between webpack 2 and 3, so that upgrade should be relatively painless. If you do run into trouble, consult [the changelog](https://github.com/webpack/webpack/releases) for the details.
+
+## `resolve.root`, `resolve.fallback`, `resolve.modulesDirectories`
+
+These three options were consolidated into a single `resolve.modules` option. See [resolving](#TODO[/configuration/resolve]) for usage.
+
+```diff
+  resolve: {
+-   root: path.join(__dirname, "src")
++   modules: [
++     path.join(__dirname, "src"),
++     "node_modules"
++   ]
+  }
+```
+
+## `resolve.extensions`
+
+You no longer need to pass an empty string in this option. That behavior moved to `resolve.enforceExtension`. See [resolving](#TODO[/configuration/resolve]) for usage.
+
+## `resolve.*`
+
+Several APIs changed here. They are not documented in detail because they are rarely used. See [resolving](#TODO[/configuration/resolve]) for the specifics.
+
+## `module.loaders` is now `module.rules`
+
+The old loader configuration has been superseded by a more capable rules system that can configure loaders and much more. For backward compatibility the old `module.loaders` syntax remains valid and the old property names are still parsed, but the new naming conventions are clearer and worth adopting by switching to `module.rules`.
+
+```diff
+  module: {
+-   loaders: [
++   rules: [
+      {
+        test: /\.css$/,
+-       loaders: [
+-         "style-loader",
+-         "css-loader?modules=true"
++       use: [
++         {
++           loader: "style-loader"
++         },
++         {
++           loader: "css-loader",
++           options: {
++             modules: true
++           }
++         }
+        ]
+      },
+      {
+        test: /\.jsx$/,
+        loader: "babel-loader", // Do not use "use" here
+        options: {
+          // ...
+        }
+      }
+    ]
+  }
+```
+
+## Chaining loaders
+
+As in webpack 1, loaders can be chained so that the output of one is passed to the next. With the [`rule.use`](#TODO[/configuration/module/#ruleuse]) option, `use` accepts an array of loaders. In webpack 1, loaders were typically chained with `!`; that style is now only supported through the legacy `module.loaders` option.
+
+```diff
+  module: {
+-   loaders: [{
++   rules: [{
+      test: /\.less$/,
+-     loader: "style-loader!css-loader!less-loader"
++     use: [
++       "style-loader",
++       "css-loader",
++       "less-loader"
++     ]
+    }]
+  }
+```
+
+## Automatic `-loader` module name extension removed
+
+You can no longer omit the `-loader` suffix when referencing loaders:
+
+```diff
+  module: {
+    rules: [
+      {
+        use: [
+-         "style",
++         "style-loader",
+-         "css",
++         "css-loader",
+-         "less",
++         "less-loader",
+        ]
+      }
+    ]
+  }
+```
+
+You can still opt back in to the old behavior with the `resolveLoader.moduleExtensions` option, though it is not recommended.
+
+```diff
++ resolveLoader: {
++   moduleExtensions: ["-loader"]
++ }
+```
+
+See [#2986](https://github.com/webpack/webpack/issues/2986) for the reasoning behind this change.
+
+## `json-loader` is no longer required
+
+When no loader is configured for a JSON file, webpack automatically loads it with [`json-loader`](https://github.com/webpack-contrib/json-loader).
+
+```diff
+  module: {
+    rules: [
+-     {
+-       test: /\.json/,
+-       loader: "json-loader"
+-     }
+    ]
+  }
+```
+
+[This change was made](https://github.com/webpack/webpack/issues/3363) to smooth out the differences in environment behavior between webpack, Node.js, and Browserify.
+
+## Loaders in configuration resolve relative to context
+
+In **webpack 1**, configured loaders resolved relative to the matched file. In **webpack 2**, they resolve relative to the `context` option instead.
+
+This fixes duplicate-module problems caused by loaders when using `npm link` or referencing modules outside the `context`. As a result, you can drop any workarounds you added for that:
+
+```diff
+  module: {
+    rules: [
+      {
+        // ...
+-       loader: require.resolve("my-loader")
++       loader: "my-loader"
+      }
+    ]
+  },
+  resolveLoader: {
+-   root: path.resolve(__dirname, "node_modules")
+  }
+```
+
+## `module.preLoaders` and `module.postLoaders` were removed
+
+```diff
+  module: {
+-   preLoaders: [
++   rules: [
+      {
+        test: /\.js$/,
++       enforce: "pre",
+        loader: "eslint-loader"
+      }
+    ]
+  }
+```
+
+## `UglifyJsPlugin` `sourceMap`
+
+The `sourceMap` option of `UglifyJsPlugin` now defaults to `false` rather than `true`. If you want source maps for minified code, or correct line numbers in uglifyjs warnings, set `sourceMap: true` explicitly.
+
+```diff
+  devtool: "source-map",
+  plugins: [
+    new UglifyJsPlugin({
++     sourceMap: true
+    })
+  ]
+```
+
+## `UglifyJsPlugin` warnings
+
+The `compress.warnings` option of `UglifyJsPlugin` now defaults to `false` rather than `true`. To see uglifyjs warnings, set `compress.warnings` to `true`.
+
+```diff
+  devtool: "source-map",
+  plugins: [
+    new UglifyJsPlugin({
++     compress: {
++       warnings: true
++     }
+    })
+  ]
+```
+
+## `UglifyJsPlugin` minimize loaders
+
+`UglifyJsPlugin` no longer switches loaders into minimize mode. In the long term, `minimize: true` must be passed through loader options instead, so check each loader's documentation for the relevant settings.
+
+The minimize mode for loaders will be removed in webpack 3 or later.
+
+For compatibility with older loaders, you can still toggle minimize mode through a plugin:
+
+```diff
+  plugins: [
++   new webpack.LoaderOptionsPlugin({
++     minimize: true
++   })
+  ]
+```
+
+## `DedupePlugin` has been removed
+
+`webpack.optimize.DedupePlugin` is no longer needed. Remove it from your configuration.
+
+## `BannerPlugin` - breaking change
+
+`BannerPlugin` no longer accepts two arguments; it takes a single options object.
+
+```diff
+  plugins: [
+-    new webpack.BannerPlugin('Banner', {raw: true, entryOnly: true});
++    new webpack.BannerPlugin({banner: 'Banner', raw: true, entryOnly: true});
+  ]
+```
+
+## `OccurrenceOrderPlugin` is now on by default
+
+`OccurrenceOrderPlugin` is now enabled by default and has been renamed (it was `OccurenceOrderPlugin` in webpack 1). Remove it from your configuration:
+
+```diff
+  plugins: [
+    // webpack 1
+-   new webpack.optimize.OccurenceOrderPlugin()
+    // webpack 2
+-   new webpack.optimize.OccurrenceOrderPlugin()
+  ]
+```
+
+## `ExtractTextWebpackPlugin` - breaking change
+
+[`ExtractTextPlugin`](https://github.com/webpack/extract-text-webpack-plugin) requires version 2 to work with webpack 2.
+
+```bash
+npm install --save-dev extract-text-webpack-plugin
+```
+
+The configuration changes for this plugin are mostly syntactical.
+
+### `ExtractTextPlugin.extract`
+
+```diff
+module: {
+  rules: [
+    {
+      test: /.css$/,
+-      loader: ExtractTextPlugin.extract("style-loader", "css-loader", { publicPath: "/dist" })
++      use: ExtractTextPlugin.extract({
++        fallback: "style-loader",
++        use: "css-loader",
++        publicPath: "/dist"
++      })
+    }
+  ]
+}
+```
+
+### `new ExtractTextPlugin({options})`
+
+```diff
+plugins: [
+-  new ExtractTextPlugin("bundle.css", { allChunks: true, disable: false })
++  new ExtractTextPlugin({
++    filename: "bundle.css",
++    disable: false,
++    allChunks: true
++  })
+]
+```
+
+## Fully dynamic requires now fail by default
+
+A dependency consisting solely of an expression (for example `require(expr)`) now creates an empty context rather than the context of the entire directory.
+
+Code like this should be refactored, since it will not work with ES2015 modules. If refactoring is not possible, you can use `ContextReplacementPlugin` to hint the compiler toward the correct resolution.
+
+> [!NOTE]
+> Link to an article about dynamic dependencies.
+
+### Using custom arguments in CLI and configuration
+
+If you previously misused the CLI to pass custom arguments into your configuration like this:
+
+```bash
+webpack --custom-stuff
+```
+
+```js
+// webpack.config.js
+const customStuff = process.argv.includes('--custom-stuff');
+
+/* ... */
+module.exports = config;
+```
+
+you will find that it is no longer permitted, since the CLI is now stricter. There is instead a dedicated interface for passing arguments into the configuration, which you should use; future tooling may depend on it.
+
+```bash
+webpack --env.customStuff
+```
+
+```js
+module.exports = function (env) {
+  const { customStuff } = env;
+  /* ... */
+  return config;
+};
+```
+
+See [CLI](#TODO[/api/cli]).
+
+## `require.ensure` and AMD `require` are asynchronous
+
+These functions are now always asynchronous, rather than invoking their callback synchronously when the chunk is already loaded.
+
+> [!WARNING]
+> `require.ensure` now depends on native `Promise`s. If you use `require.ensure` in an environment that lacks them, you will need a polyfill.
+
+## Loader configuration is through `options`
+
+You can _no longer_ configure a loader with a custom property in `webpack.config.js`; it must be done through `options`. The following configuration, which uses a top-level `ts` property, is no longer valid in webpack 2:
+
+```js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.tsx?$/,
+        loader: 'ts-loader',
+      },
+    ],
+  },
+  // does not work with webpack 2
+  ts: { transpileOnly: false },
+};
+```
+
+### What are `options`?
+
+Good question. Strictly speaking, `options` refers to two possible things, both ways of configuring a webpack loader. Historically `options` was called `query`, and was a string appended to the loader name, much like a query string but with [greater capabilities](https://github.com/webpack/loader-utils#parsequery):
+
+```js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.tsx?$/,
+        loader: `ts-loader?${JSON.stringify({ transpileOnly: false })}`,
+      },
+    ],
+  },
+};
+```
+
+Alternatively, it can be a separate object supplied alongside the loader:
+
+```js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.tsx?$/,
+        loader: 'ts-loader',
+        options: { transpileOnly: false },
+      },
+    ],
+  },
+};
+```
+
+## `LoaderOptionsPlugin` context
+
+Some loaders need contextual information and read it from the configuration. In the long term, this should be passed through loader options, so check each loader's documentation for the relevant settings.
+
+For compatibility with older loaders, the information can still be passed through a plugin:
+
+```diff
+  plugins: [
++   new webpack.LoaderOptionsPlugin({
++     options: {
++       context: __dirname
++     }
++   })
+  ]
+```
+
+## `debug`
+
+In webpack 1, the `debug` option switched loaders into debug mode. In the long term, this should be passed through loader options, so check each loader's documentation for the relevant settings.
+
+The debug mode for loaders will be removed in webpack 3 or later.
+
+For compatibility with older loaders, you can still switch them into debug mode through a plugin:
+
+```diff
+- debug: true,
+  plugins: [
++   new webpack.LoaderOptionsPlugin({
++     debug: true
++   })
+  ]
+```
+
+## Code splitting with ES2015
+
+In webpack 1, you could use [`require.ensure()`](#TODO[/api/module-methods/#requireensure]) to lazily load chunks of your application:
+
+```js
+require.ensure([], require => {
+  const foo = require('./module');
+});
+```
+
+The ES2015 loader spec defines [`import()`](#TODO[/api/module-methods/#import-1]) as the way to load ES2015 modules dynamically at runtime. webpack treats `import()` as a split point and places the requested module in a separate chunk. `import()` takes the module name as its argument and returns a Promise.
+
+```js
+function onClick() {
+  import('./module')
+    .then(module => module.default)
+    .catch(err => {
+      console.log('Chunk loading failed');
+    });
+}
+```
+
+A welcome benefit: because loading is now Promise-based, you can handle the failure to load a chunk.
+
+## Dynamic expressions
+
+You can pass a partial expression to `import()`. This works much like expressions in CommonJS: webpack creates a [context](#TODO[/plugins/context-replacement-plugin/]) containing all possible files, and `import()` produces a separate chunk for each possible module.
+
+```js
+function route(path, query) {
+  return import(`./routes/${path}/route`).then(route => new route.Route(query));
+}
+// This creates a separate chunk for each possible route
+```
+
+## Mixing ES2015 with AMD and CommonJS
+
+As with AMD and CommonJS, you can freely mix all three module types, even within a single file. webpack behaves much like Babel and node-eps here:
+
+```js
+// CommonJS consuming ES2015 Module
+const book = require('./book');
+
+book.currentPage;
+book.readPage();
+book.default === 'This is a book';
+```
+
+```js
+// ES2015 Module consuming CommonJS
+import fs from 'node:fs'; // module.exports maps to default
+
+typeof fs.readFileSync === 'function';
+```
+
+```js
+// ES2015 Module consuming CommonJS
+import { readFileSync } from 'node:fs'; // named exports are read from the returned object
+
+typeof readFileSync === 'function';
+```
+
+Note that you will want to tell Babel not to parse these module symbols, so that webpack can use them. Do this by adding the following to your `.babelrc` or `babel-loader` options.
+
+```json displayName=".babelrc"
+{
+  "presets": [["es2015", { "modules": false }]]
+}
+```
+
+## Hints
+
+Nothing here is required, but each is an opportunity to improve your setup.
+
+### Template strings
+
+webpack now supports template strings in expressions, so you can use them in webpack constructs:
+
+```diff
+- require("./templates/" + name);
++ require(`./templates/${name}`);
+```
+
+### Configuration Promise
+
+webpack now supports returning a `Promise` from the configuration file, which allows asynchronous processing during configuration.
+
+```js displayName="webpack.config.js"
+module.exports = function () {
+  return fetchLangs().then(lang => ({
+    entry: '...',
+    // ...
+    plugins: [new DefinePlugin({ LANGUAGE: lang })],
+  }));
+};
+```
+
+### Advanced loader matching
+
+webpack now supports more ways to match loaders.
+
+```js
+module.exports = {
+  // ...
+  module: {
+    rules: [
+      {
+        resource: /filename/, // matches "/path/filename.js"
+        resourceQuery: /^\?querystring$/, // matches "?querystring"
+        issuer: /filename/, // matches "/path/something.js" if requested from "/path/filename.js"
+      },
+    ],
+  },
+};
+```
+
+### More CLI options
+
+Several new CLI options are available:
+
+- `--define process.env.NODE_ENV="production"` — see [`DefinePlugin`](#TODO[/plugins/define-plugin/]).
+- `--display-depth` — displays the distance from the entry point for each module.
+- `--display-used-exports` — displays which exports are used in a module.
+- `--display-max-modules` — sets how many modules appear in the output (defaults to 15).
+- `-p` — now also defines `process.env.NODE_ENV` as `"production"`.
+
+## Loader changes
+
+The following changes are relevant only to loader authors.
+
+### Cacheable
+
+Loaders are now cacheable by default. A loader must opt out if it is not cacheable.
+
+```diff
+  // Cacheable loader
+  module.exports = function(source) {
+-   this.cacheable();
+    return source;
+  }
+```
+
+```diff
+  // Not cacheable loader
+  module.exports = function(source) {
++   this.cacheable(false);
+    return source;
+  }
+```
+
+### Complex options
+
+**webpack 1** supports only `JSON.stringify`-able options for loaders, whereas **webpack 2** supports any JavaScript object as loader options.
+
+Before webpack [2.2.1](https://github.com/webpack/webpack/releases/tag/v2.2.1) (that is, from 2.0.0 through 2.2.0), complex options required an `ident` on the `options` object so that it could be referenced from other loaders. **This was removed in 2.2.1**, so current migrations do not need the `ident` key.
+
+```diff
+{
+  test: /\.ext/
+  use: {
+    loader: '...',
+    options: {
+-     ident: 'id',
+      fn: () => require('./foo.js')
+    }
+  }
+}
+```
diff --git a/pages/guides/migration/to-v4.md b/pages/guides/migration/to-v4.md
new file mode 100644
index 00000000..8bb126b0
--- /dev/null
+++ b/pages/guides/migration/to-v4.md
@@ -0,0 +1,147 @@
+---
+authors: sokra,EugeneHlushko,Kolhar730,avivkeller
+---
+
+# To v4 from v3
+
+This guide covers only the major changes that affect end users. For the full picture, see [the changelog](https://github.com/webpack/webpack/releases).
+
+## Node.js v4
+
+If you are still on Node.js v4 or lower, upgrade your Node.js installation to v6 or higher.
+
+You can find instructions for upgrading Node.js [here](https://stackoverflow.com/questions/10075990/upgrading-node-js-to-latest-version).
+
+## CLI
+
+The CLI has moved into its own package, `webpack-cli`. You must install it before using webpack; see [basic setup](#TODO[/guides/getting-started/#basic-setup]).
+
+The installation guide is available [here](#TODO[/guides/installation]).
+
+## Update plugins
+
+Many third-party plugins need to be updated to their latest versions to be compatible with webpack 4. Links to popular plugins can be found [here](#TODO[/awesome-webpack/#webpack-plugins]).
+
+## `mode`
+
+Add the new [`mode`](#TODO[/configuration/mode/]) option to your configuration, setting it to `'production'`, `'development'`, or `'none'` depending on your use case.
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
++  mode: 'production',
+}
+```
+
+> [!TIP]
+> `'development'` mode and `'production'` mode serve different purposes. You can use `webpack-merge`, as shown in the [production guide](#TODO[/guides/production/#setup]), to maintain separate optimized configurations.
+
+## Deprecated and removed plugins
+
+The following plugins can be removed from your configuration because they are enabled by default in production mode:
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
+  plugins: [
+-    new NoEmitOnErrorsPlugin(),
+-    new ModuleConcatenationPlugin(),
+-    new DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") })
+-    new UglifyJsPlugin()
+  ],
+}
+```
+
+These plugins are enabled by default in development mode:
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
+  plugins: [
+-    new NamedModulesPlugin()
+  ],
+}
+```
+
+These plugins were deprecated and have now been removed:
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
+  plugins: [
+-    new NoErrorsPlugin(),
+-    new NewWatchingPlugin()
+  ],
+}
+```
+
+## `CommonsChunkPlugin`
+
+`CommonsChunkPlugin` has been removed. Use the [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) options instead.
+
+See the [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) documentation for details. The default configuration may already meet your needs.
+
+> [!TIP]
+> When generating HTML from the stats, you can set `optimization.splitChunks.chunks: "all"`, which is the optimal configuration in most cases.
+
+## `import()` and CommonJS
+
+When using `import()` to load a non-ESM module, the result has changed in webpack 4. You now need to access the `default` property to get the value of `module.exports`.
+
+```js displayName="non-esm.js"
+module.exports = {
+  sayHello: () => {
+    console.log('hello world');
+  },
+};
+```
+
+```js displayName="example.js"
+function sayHello() {
+  import('./non-esm.js').then(module => {
+    module.default.sayHello();
+  });
+}
+```
+
+## JSON and loaders
+
+When using a custom loader to transform `.json` files, you now need to change the module `type`:
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
+  rules: [
+    {
+      test: /config\.json$/,
+      loader: 'special-loader',
++     type: 'javascript/auto',
+      options: {...}
+    }
+  ]
+};
+```
+
+If you are still using `json-loader`, you can remove it:
+
+```diff displayName="webpack.config.js"
+module.exports = {
+  // ...
+  rules: [
+    {
+-     test: /\.json$/,
+-     loader: 'json-loader'
+    }
+  ]
+};
+```
+
+## `module.loaders`
+
+`module.loaders` was deprecated in webpack 2 and is now removed in favor of [`module.rules`](#TODO[/configuration/module/#rule]).
+
+## Further reading
+
+- [To v2 or v3 from v1](https://webpack.js.org/migrate/3/)
+- [RIP CommonChunkPlugin](https://gist.github.com/sokra/1522d586b8e5c0f5072d7565c2bee693)
+- [webpack 4: migration guide for plugins/loaders](https://medium.com/webpack/webpack-4-migration-guide-for-plugins-loaders-20a79b927202)
diff --git a/pages/guides/migration/to-v5.md b/pages/guides/migration/to-v5.md
new file mode 100644
index 00000000..e5f40ea8
--- /dev/null
+++ b/pages/guides/migration/to-v5.md
@@ -0,0 +1,339 @@
+---
+authors: sokra,salemhilal,keichinger,EugeneHlushko,MattGoldwater,rramaa,chenxsan,jamesgeorge007,getsnoopy,yevhen-logosha,akash-kumar-dev,EvanSanderson,avivkeller
+---
+
+# To v5 from v4
+
+This guide helps you migrate to webpack 5 when you use webpack directly. If you rely on a higher-level tool to run webpack, follow that tool's own migration instructions instead.
+
+## Preparations
+
+webpack 5 requires at least Node.js 10.13.0 (LTS), so upgrade your Node.js installation if you are still running an older version.
+
+## Upgrade webpack 4 and its plugins and loaders
+
+1. Upgrade `webpack` 4 to the latest available version.
+   - If you are already on webpack >= 4, upgrading to the latest webpack 4 release should not require additional guidance.
+   - If you are on a version earlier than 4, follow the [webpack 4 migration guide](#TODO[/migrate/4/]) first.
+
+2. Upgrade `webpack-cli` to the latest available version (if you use it).
+
+3. Upgrade all of your plugins and loaders to their latest available versions.
+
+   Some plugins and loaders may have a beta version that is required for webpack 5 compatibility. Read each plugin's and loader's release notes when upgrading, since the latest version might only support webpack 5 and fail on v4. In that case, upgrade to the latest version that still supports webpack 4.
+
+## Codemods
+
+To assist with upgrading from webpack v4 to v5, [Codemod](https://github.com/codemod-com/codemod) provides open-source community codemods that automate much of the migration.
+
+Note that these are not official webpack codemods, and while they aim to streamline the process, they may not cover every case. You may still need to perform additional manual steps to complete the upgrade.
+
+Run the [webpack v5 migration codemods](https://go.codemod.com/webpack-v5-recipe):
+
+```bash
+npx codemod@latest webpack/v5/migration-recipe
+```
+
+This runs the following codemods from the [Codemod registry](https://codemod.com/registry):
+
+- [`webpack/v5/set-target-to-false-and-update-plugins`](https://go.codemod.com/webpack-set-target-false)
+- [`webpack/v5/migrate-library-target-to-library-object`](https://go.codemod.com/webpack-migrate-library-target)
+- [`webpack/v5/json-imports-to-default-imports`](https://go.codemod.com/webpack-json-imports)
+
+Each of these automates a change described in this migration guide. For the complete list of available webpack v5 codemods, see the [Codemod Registry](https://go.codemod.com/webpack-v5).
+
+### Make sure your build has no errors or warnings
+
+The upgraded versions of `webpack`, `webpack-cli`, your plugins, and your loaders may introduce new errors or warnings. Watch for deprecation warnings during the build.
+
+You can run `webpack` like this to get stack traces for deprecation warnings, which helps identify the responsible plugins and loaders:
+
+```bash
+node --trace-deprecation node_modules/webpack/bin/webpack.js
+```
+
+Because webpack 5 removes all deprecated features, make sure there are no webpack deprecation warnings during the build before you proceed.
+
+### Make sure to use `mode`
+
+Set `mode` to either [`production`](#TODO[/configuration/mode/#mode-production]) or [`development`](#TODO[/configuration/mode/#mode-development]) so that the corresponding defaults are applied.
+
+### Update outdated options
+
+Update the following options to their new form (if you use them):
+
+- `optimization.hashedModuleIds: true` → `optimization.moduleIds: 'hashed'`
+- `optimization.namedChunks: true` → `optimization.chunkIds: 'named'`
+- `optimization.namedModules: true` → `optimization.moduleIds: 'named'`
+- `NamedModulesPlugin` → `optimization.moduleIds: 'named'`
+- `NamedChunksPlugin` → `optimization.chunkIds: 'named'`
+- `HashedModuleIdsPlugin` → `optimization.moduleIds: 'hashed'`
+- `optimization.noEmitOnErrors: false` → `optimization.emitOnErrors: true`
+- `optimization.occurrenceOrder: true` → `optimization: { chunkIds: 'total-size', moduleIds: 'size' }`
+- `optimization.splitChunks.cacheGroups.vendors` → `optimization.splitChunks.cacheGroups.defaultVendors`
+- `optimization.splitChunks.cacheGroups.test(module, chunks)` → `optimization.splitChunks.cacheGroups.test(module, { chunkGraph, moduleGraph })`
+- `Compilation.entries` → `Compilation.entryDependencies`
+- `serve` → removed in favor of [`DevServer`](#TODO[/configuration/dev-server/])
+- [`Rule.query`](#TODO[/configuration/module/#ruleoptions--rulequery]) (deprecated since v3) → `Rule.options` / `UseEntry.options`
+- `Rule.loaders` → [`Rule.use`](#TODO[/configuration/module/#ruleuse])
+
+> [!TIP]
+> Review the detailed configuration changes [here](#TODO[/blog/2020-10-10-webpack-5-release/#changes-to-the-configuration]).
+
+### Test webpack 5 compatibility
+
+Set the following options in your webpack 4 configuration and confirm that the build still works correctly.
+
+```js
+export default {
+  // ...
+  node: {
+    Buffer: false,
+    process: false,
+  },
+};
+```
+
+Remove these options again when you upgrade your configuration for webpack 5.
+
+> [!TIP]
+> webpack 5 removes these options from the configuration schema and always treats them as `false`.
+
+## Upgrade webpack to 5
+
+Now upgrade webpack to version 5:
+
+- npm: `npm install webpack@latest`
+- Yarn: `yarn add webpack@latest`
+- pnpm: `pnpm add webpack@latest`
+
+If you were unable to upgrade some plugins or loaders to their latest versions in the earlier step, upgrade them now.
+
+### Clean up configuration
+
+- Consider removing `optimization.moduleIds` and `optimization.chunkIds` from your configuration. The defaults may be better, because they support long-term caching in [`production` mode](#TODO[/configuration/mode/#mode-production]) and easier debugging in [`development` mode](#TODO[/configuration/mode/#mode-development]).
+- If you use the `[hash]` placeholder in your configuration, consider switching to `[contenthash]`. It is not identical, but has proven more effective.
+- If you use Yarn's PnP with the `pnp-webpack-plugin`, good news: it is now supported by default, so remove the plugin from your configuration.
+- If you use `IgnorePlugin` with a regular expression argument, it now takes an `options` object: `new IgnorePlugin({ resourceRegExp: /regExp/ })`.
+- If you use something like `node.fs: 'empty'`, replace it with `resolve.fallback.fs: false`.
+- If you use `watch: true` in the webpack Node.js API, remove it. It is unnecessary, since the compiler method you call already indicates watch mode: `watch()` for watching and `run()` for a single build.
+- If you have `rules` that load assets with `raw-loader`, `url-loader`, or `file-loader`, use [Asset Modules](#TODO[/guides/asset-modules/]) instead, as those loaders will be deprecated soon.
+- If you have `target` set to a function, set it to `false` and apply that function in the `plugins` option instead. For example:
+
+  ```json
+  // for webpack 4
+  {
+      target: WebExtensionTarget(nodeConfig)
+  }
+
+  // for webpack 5
+  {
+      target: false,
+      plugins: [
+          WebExtensionTarget(nodeConfig)
+      ]
+  }
+  ```
+
+  > **Note**: Codemod for this change:
+  >
+  > ```bash
+  > npx codemod webpack/v5/set-target-to-false-and-update-plugins
+  > ```
+  >
+  > (See the [registry here](https://codemod.com/registry/webpack-v5-set-target-to-false-and-update-plugins).)
+
+- If you have `output.library` or `output.libraryTarget` defined, rename the properties (`output.libraryTarget` → `output.library.type`, `output.library` → `output.library.name`). For example:
+
+  ```json
+  // for webpack 4
+  {
+      output: {
+        library: 'MyLibrary',
+        libraryTarget: 'commonjs2'
+      }
+  }
+
+  // for webpack 5
+  {
+      output: {
+        library: {
+          name: 'MyLibrary',
+          type: 'commonjs2'
+        }
+      }
+  }
+  ```
+
+  > **Note**: Codemod for this change:
+  >
+  > ```bash
+  > npx codemod webpack/v5/migrate-library-target-to-library-object
+  > ```
+  >
+  > (See the [registry here](https://codemod.com/registry/webpack-v5-migrate-library-target-to-library-object).)
+
+If you were importing WebAssembly, follow this two-step process:
+
+- Enable the deprecated spec by setting `experiments.syncWebAssembly: true`, which reproduces the webpack 4 behavior.
+- After successfully migrating to webpack 5, switch to `experiments: { asyncWebAssembly: true }` to use the up-to-date WASM integration spec.
+
+Reconsider `optimization.splitChunks`:
+
+- It is recommended to use either the defaults or `optimization.splitChunks: { chunks: 'all' }`.
+- If you use a custom configuration, drop `name: false` and replace `name: string | function` with `idHint: string | function`.
+- It used to be possible to turn off the defaults with `optimization.splitChunks.cacheGroups: { default: false, vendors: false }`. We do not recommend this, but if you really want the same effect in webpack 5, use `optimization.splitChunks.cacheGroups: { default: false, defaultVendors: false }`.
+
+Consider removing values that are now defaults:
+
+- `entry: './src/index.js'` — you can omit it; it is the default.
+- `output.path: path.resolve(__dirname, 'dist')` — you can omit it; it is the default.
+- `output.filename: '[name].js'` — you can omit it; it is the default.
+
+### Need to support an older browser like IE 11?
+
+- If you have [browserslist](https://github.com/browserslist/browserslist) enabled for your project, webpack 5 will reuse your `browserslist` config to decide which code style to emit for the runtime code.
+
+  Make sure to:
+  1. Set [`target`](#TODO[/configuration/target/#root]) to `browserslist`, or remove `target` and let webpack set `browserslist` automatically.
+  2. Add `IE 11` to your browserslist configuration.
+
+- Without a `browserslist`, webpack's runtime code uses ES2015 syntax (for example, arrow functions) to produce smaller bundles. In that case, set `target: ['web', 'es5']` to emit ES5 syntax for browsers (such as IE 11) that do not support ES2015.
+- For Node.js builds, include the supported Node.js version in the `target` option, and webpack will work out which syntax is supported. For example, `target: 'node8.6'`.
+
+### Clean up the code
+
+#### Using `/* webpackChunkName: '...' */`
+
+Be clear about the intent:
+
+- The chunk's name here is meant to be public.
+- It is not a development-only name.
+- webpack uses it to name files in both production and development modes.
+- webpack 5 automatically assigns useful file names in `development` mode even without `webpackChunkName`.
+
+#### Using named exports from JSON modules
+
+This is not supported by the new specification, and you will get a warning. Instead of:
+
+```js
+import { version } from './package.json';
+
+console.log(version);
+```
+
+use:
+
+```js
+import pkg from './package.json';
+
+console.log(pkg.version);
+```
+
+> **Note**: Codemod for this change:
+>
+> ```bash
+> npx codemod webpack/v5/json-imports-to-default-imports
+> ```
+>
+> (See the [registry here](https://codemod.com/registry/webpack-v5-json-imports-to-default-imports).)
+
+#### Clean up the build code
+
+- When using `const compiler = webpack(...);`, close the compiler after you are done with it: `compiler.close(callback);`.
+  - This does not apply to the `webpack(..., callback)` form, which closes automatically.
+  - This is optional if you use webpack in watch mode until the user ends the process. The idle phases in watch mode are used for this kind of work.
+
+### Run a single build and follow the advice
+
+Read the build errors and warnings carefully. If there is no corresponding advice, please open an issue and we will try to resolve it.
+
+Repeat the following steps until you have at least reached level 3 or 4:
+
+- Level 1: **Schema validation fails.**
+
+  Configuration options have changed. There should be a validation error with a `BREAKING CHANGE:` note, or a hint about which option to use instead.
+
+- Level 2: **webpack exits with an error.**
+
+  The error message should tell you what to change.
+
+- Level 3: **Build errors.**
+
+  The error message should include a `BREAKING CHANGE:` note.
+
+- Level 4: **Build warnings.**
+
+  The warning message should tell you what can be improved.
+
+- Level 5: **Runtime errors.**
+
+  These are tricky; you will probably need to debug to find the problem. General advice is difficult here, but a few common cases are listed below:
+  - `process` is not defined.
+    - webpack 5 no longer includes a polyfill for this Node.js variable. Avoid using it in frontend code.
+    - Want to support browser usage? Use the `exports` or `imports` field in `package.json` to serve different code depending on the environment.
+      - Also use the `browser` field to support older bundlers.
+      - Alternatively, wrap code blocks with `typeof process` checks. Note that this increases bundle size.
+    - Want to use environment variables via `process.env.VARIABLE`? Use `DefinePlugin` or `EnvironmentPlugin` to define those variables in your configuration.
+      - Consider using `VARIABLE` directly instead, and check `typeof VARIABLE !== 'undefined'` as well. `process.env` is Node.js-specific and should be avoided in frontend code.
+  - 404 errors pointing to URLs containing `auto`.
+    - Not all ecosystem tooling is ready for the new default automatic `publicPath` (`output.publicPath: "auto"`).
+      - Use a static `output.publicPath: ""` instead.
+  - `Cannot read properties of undefined (reading 'call')`.
+    - If you see this at runtime, it may be related to the [ModuleConcatenationPlugin](https://webpack.js.org/plugins/module-concatenation-plugin/). Check whether you are using the plugin: if you have added it to the `plugins` section of a config that is also set to `production` mode, remove it (for example, `new webpack.optimize.ModuleConcatenationPlugin()`). In webpack 5 the plugin is enabled by default in production mode, so it may get included twice.
+    - In general, disabling each plugin and testing the build is a good way to narrow down where the issue comes from.
+    - See [this issue](https://github.com/webpack/webpack/discussions/15369#discussioncomment-13420496) for more details.
+
+- Level 6: **Deprecation warnings.**
+
+  You will probably see many deprecation warnings. This is not directly a problem; plugins need time to catch up with core changes. Please report these deprecations to the affected plugins. They are only warnings, and the build will still work with minor drawbacks (such as reduced performance).
+  - You can hide deprecation warnings by running Node with the `--no-deprecation` flag, for example: `node --no-deprecation node_modules/webpack/bin/webpack.js`. This should only be a temporary workaround.
+  - Plugin and loader authors can follow the advice in the deprecation messages to improve their code.
+
+- Level 7: **Performance issues.**
+
+  Performance usually improves with webpack 5, but there are a few cases where it gets worse.
+
+  Here are some things you can do to improve the situation:
+  - Profile where the time is spent.
+    - `--profile --progress` now displays a simple performance profile.
+    - `node --inspect-brk node_modules/webpack/bin/webpack.js` together with [`chrome://inspect`](chrome://inspect) or [`edge://inspect`](edge://inspect) (see the profiler tab).
+      - You can save these profiles to files and attach them to issues.
+      - Try the `--no-turbo-inlining` flag for better stack traces in some cases.
+  - Module build time for incremental builds can be improved by reverting to unsafe caching like in webpack 4:
+    - `module.unsafeCache: true`
+    - However, this may affect the ability to handle some changes to the code base.
+  - Full builds:
+    - The backward-compatibility layer for deprecated features generally performs worse than the new features.
+    - Generating many warnings can hurt build performance, even when those warnings are ignored.
+    - Source maps are expensive. Check the [`devtool`](#TODO[/configuration/devtool/]) option in the documentation for a comparison of the available choices.
+    - Anti-virus protection can affect the performance of file system access.
+    - Persistent caching can improve repeated full builds.
+    - Module Federation lets you split the application into several smaller builds.
+
+## Everything works?
+
+Please tweet that you have successfully migrated to webpack 5. [Tweet it](https://twitter.com/intent/tweet?source=https://webpack.js.org/migrate/5/&text=I%20just%20migrated%20to%20webpack%205%20using%20its%20migration%20guide!%20&via=webpack&hashtags=webpack,webpack5)
+
+## It is not working?
+
+Create an [issue](https://github.com/webpack/webpack/issues/new?template=Bug_report.md) and tell us about the problems you encountered during the migration.
+
+## Something missing in this guide?
+
+Please open a [Pull Request](https://github.com/webpack/webpack.js.org/edit/main/src/content/migrate/5.mdx) to help the next person who uses this guide.
+
+## Changes to internals
+
+The following changes to webpack internals (added types, refactored code, renamed methods) are listed here for anyone interested, but they are not part of the common migration path.
+
+- `Module.nameForCondition`, `Module.updateCacheModule`, and `Module.chunkCondition` are no longer optional.
+
+### `getOptions` method for loaders
+
+webpack 5 ships with a built-in [`this.getOptions`](#TODO[/api/loaders/#thisgetoptionsschema]) method available in the loader context. This is a breaking change for loaders that previously used the `getOptions` method from [schema-utils](https://github.com/webpack/schema-utils):
+
+- `this.getOptions` is available since webpack 5.
+- It supports JSON rather than JSON5 as a query string: `?{arg:true}` → `?{"arg":true}`. Using JSON5 should be considered deprecated and documented as such in each loader's documentation, in favor of JSON.
+- [`loader-utils`](https://github.com/webpack/loader-utils) had specific behavior for parsing query strings (`true`, `false`, and `null` were parsed as primitives rather than strings). This is no longer the case for the new built-in `this.getOptions` method, which uses Node.js's native [`querystring`](https://nodejs.org/api/querystring.html) parsing. You can still add custom handling for these cases in your loader's code after calling `this.getOptions`.
+- The schema argument is optional for the new `this.getOptions` method, but we strongly recommend adding schema validation for your loader's options. The `title` field in the schema can customize the validation error message; for example, `"title": "My Loader ooooptions"` produces errors like `Invalid ooooptions object. My Loader has been initialised using an ooooptions object that does not match the API schema. - ooooptions.foo.bar.baz should be a string.`
diff --git a/pages/guides/modern-web/index.md b/pages/guides/modern-web/index.md
new file mode 100644
index 00000000..542a46f1
--- /dev/null
+++ b/pages/guides/modern-web/index.md
@@ -0,0 +1,189 @@
+---
+authors: phoekerson,avivkeller
+---
+
+# Modern Web Platform
+
+This guide describes practical webpack patterns for **Web Components**, **Import Maps**, and **Progressive Web Apps** (PWAs) with **Service Workers**. Each section states the problem, shows a minimal configuration you can copy, and notes the current limits relative to future webpack improvements.
+
+> [!TIP]
+> Familiarity with [code splitting](#TODO[/guides/code-splitting/]), [caching](#TODO[/guides/caching/]) (`[contenthash]`), and the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is helpful here.
+
+## Web Components with webpack
+
+### Problem
+
+If more than one JavaScript bundle calls `customElements.define()` for the same tag name, the browser throws a [`DOMException`](https://developer.mozilla.org/en-US/docs/Web/API/DOMException): `Failed to execute 'define' on 'CustomElementRegistry'`. This often happens when the module that registers an element is duplicated: separate entry points or async chunks each contain a copy of the registration code, so two bundles both run `define` for the same tag.
+
+### Approach
+
+Use [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) so the module that defines the element lives in a **single shared chunk** that loads once. Adjust `cacheGroups` so your element definitions (or a dedicated folder such as `src/elements/`) are forced into one chunk. See [Prevent Duplication](#TODO[/guides/code-splitting/#prevent-duplication]) for the general idea.
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: {
+    main: './src/main.js',
+    admin: './src/admin.js',
+  },
+  output: {
+    filename: '[name].js',
+    path: path.resolve(__dirname, 'dist'),
+    clean: true,
+  },
+  optimization: {
+    splitChunks: {
+      chunks: 'all',
+      cacheGroups: {
+        // Put shared custom element modules in one async chunk.
+        customElements: {
+          test: /[\\/]src[\\/]elements[\\/]/,
+          name: 'custom-elements',
+          chunks: 'all',
+          enforce: true,
+        },
+      },
+    },
+  },
+};
+```
+
+Ensure both entries import the same registration module (for example, `./elements/my-element.js`) so webpack can emit one `custom-elements.js` chunk instead of inlining duplicate registration in `main` and `admin`.
+
+### Limitations and future work
+
+Splitting alone does not change **browser** rules: the tag name must still be registered exactly once per document. webpack does not yet provide a first-class "register this custom element once" primitive beyond chunk graph control. Native support for deduplicating custom element registration across the build is **planned**; until then, rely on shared chunks and a single registration module.
+
+## Import Maps with webpack
+
+### Problem
+
+[Import maps](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap) let the browser resolve **bare specifiers** (such as `import "lodash-es"`) from an `importmap.json` file or an inline `<script type="importmap">`. If webpack **bundles** those dependencies, you don't need an import map for them. If you want the **browser** to load a dependency from a URL (a CDN or `/vendor/`) while your application code keeps bare imports, mark those modules as [`externals`](#TODO[/configuration/externals/]) so webpack emits `import` statements that match your map.
+
+### Approach
+
+Enable [ES module output](#TODO[/configuration/output/#outputmodule]) (`experiments.outputModule` and `output.module`), set [`externalsType: "module"`](#TODO[/configuration/externals/#externalstypemodule]) for static imports, and list each bare specifier in `externals` using the same string the browser will resolve via the import map.
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  mode: 'production',
+  experiments: {
+    outputModule: true,
+  },
+  entry: './src/index.js',
+  externalsType: 'module',
+  externals: {
+    'lodash-es': 'lodash-es',
+  },
+  output: {
+    module: true,
+    filename: '[name].mjs',
+    path: path.resolve(__dirname, 'dist'),
+    clean: true,
+  },
+};
+```
+
+For the import map itself (served alongside your HTML, with URLs that must match your deployment), use a local vendor file:
+
+```json displayName="importmap.json"
+{
+  "imports": {
+    "lodash-es": "/vendor/lodash-es.js"
+  }
+}
+```
+
+Or use a CDN (no self-hosting required):
+
+```json displayName="importmap.json"
+{
+  "imports": {
+    "lodash-es": "https://cdn.jsdelivr.net/npm/lodash-es@4/+esm"
+  }
+}
+```
+
+The key `"lodash-es"` must match both the **`externals` key** and the **specifier** in your source (`import … from "lodash-es"`). The value is the URL the browser loads — either a local path or a CDN URL; webpack does not validate that file.
+
+The order matters: the import map must come before your bundle.
+
+```html displayName="index.html"
+<script type="importmap" src="/importmap.json"></script>
+<script type="module" src="/dist/main.mjs"></script>
+```
+
+> [!WARNING]
+> [`experiments.outputModule`](#TODO[/configuration/experiments/#experimentsoutputmodule]) and [`output.module`](#TODO[/configuration/output/#outputmodule]) are still experimental. Check the latest [webpack release notes](https://github.com/webpack/webpack/releases) before relying on them in production.
+
+### Limitations and future work
+
+webpack **does not** emit or update `importmap.json` for you. You must maintain the map so specifiers and URLs stay aligned with `externals` and your server layout. Automatic import-map generation is **not** available in webpack 5 today; future tooling may reduce this manual step.
+
+## Progressive Web Apps (PWA) and Service Workers
+
+### Problem
+
+Long-lived caching requires **stable URLs** for HTML but **versioned URLs** for scripts and styles. Using [`[contenthash]`](#TODO[/guides/caching/]) in `output.filename` changes those URLs every build. A **service worker** precache list must list the **exact** URLs after each build, or offline shells will point at missing files.
+
+The [`workbox-webpack-plugin`](#TODO[/guides/progressive-web-application/]) **`GenerateSW`** plugin generates an entire service worker for you. That is convenient, but when you need **full control** over the service worker code (custom routing, `skipWaiting` behavior, or coordination with `[contenthash]` and other plugins), **`InjectManifest`** is appropriate: you write the worker, and Workbox injects the precache manifest at build time from webpack's asset list.
+
+### Approach
+
+Use `[contenthash]` for emitted assets and add **`InjectManifest`** from `workbox-webpack-plugin`. Your source template imports `workbox-precaching` and calls `precacheAndRoute(self.__WB_MANIFEST)`; the plugin replaces `self.__WB_MANIFEST` with the list of webpack assets (including hashed filenames).
+
+Install the packages:
+
+```bash
+npm install workbox-webpack-plugin workbox-precaching --save-dev
+```
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import HtmlWebpackPlugin from 'html-webpack-plugin';
+import { InjectManifest } from 'workbox-webpack-plugin';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: '[name].[contenthash].js',
+    path: path.resolve(__dirname, 'dist'),
+    clean: true,
+  },
+  plugins: [
+    new HtmlWebpackPlugin({ title: 'PWA + content hashes' }),
+    new InjectManifest({
+      swSrc: path.resolve(__dirname, 'src/service-worker.js'),
+      swDest: 'service-worker.js',
+    }),
+  ],
+};
+```
+
+```js displayName="src/service-worker.js"
+import { precacheAndRoute } from 'workbox-precaching';
+
+// Replaced at build time with webpack's precache manifest (hashed asset URLs).
+precacheAndRoute(globalThis.__WB_MANIFEST);
+```
+
+Register the emitted `service-worker.js` from your app (for example, in `src/index.js`) with `navigator.serviceWorker.register("/service-worker.js")`, served from `dist/` with the correct scope.
+
+### Limitations and future work
+
+You must keep **`InjectManifest`** in sync with your output filenames and plugins; `GenerateSW` remains the simpler path when you don't need a custom worker. webpack does not ship a built-in service worker precache generator, though tighter integration with hashed assets may arrive in future releases. Until then, Workbox's **`InjectManifest`** is a well-supported way to align `[contenthash]` output with precaching.
diff --git a/pages/guides/modern-web/native-css.md b/pages/guides/modern-web/native-css.md
new file mode 100644
index 00000000..ed6d7684
--- /dev/null
+++ b/pages/guides/modern-web/native-css.md
@@ -0,0 +1,250 @@
+---
+authors: phoekerson,avivkeller
+---
+
+# Native CSS
+
+This guide walks through webpack's built-in CSS handling, enabled with `experiments.css`.
+
+> [!WARNING]
+> `experiments.css` is still experimental. It is expected to become the default in webpack v6, but its behavior may continue to change while development is ongoing.
+
+## Getting started
+
+Turn on native CSS support in your webpack configuration:
+
+```js displayName="webpack.config.js"
+export default {
+  experiments: {
+    css: true,
+  },
+};
+```
+
+With this option enabled, webpack can process CSS without `css-loader` or `mini-css-extract-plugin` for the basic flow.
+
+## Importing CSS
+
+Once the experiment is enabled, you can import `.css` files directly from JavaScript:
+
+```js displayName="src/index.js"
+import './styles.css';
+
+const element = document.createElement('h1');
+element.textContent = 'Hello native CSS';
+document.body.appendChild(element);
+```
+
+```css displayName="src/styles.css"
+h1 {
+  color: #1f6feb;
+}
+```
+
+webpack processes the CSS and includes it in the build output.
+
+## CSS Modules
+
+Native CSS support also covers CSS Modules. The recommended approach is to:
+
+- keep `type: "css/auto"` for mixed CSS handling, and
+- use the `.module.css` (or `.modules.css`) naming convention for CSS Modules files.
+
+```css displayName="src/button.module.css"
+.button {
+  background: #0d6efd;
+  color: white;
+  border: 0;
+  border-radius: 4px;
+  padding: 8px 12px;
+}
+```
+
+```js displayName="src/index.js"
+import * as styles from './button.module.css';
+
+const button = document.createElement('button');
+button.className = styles.button;
+button.textContent = 'Click me';
+document.body.appendChild(button);
+```
+
+> [!TIP]
+> CSS Modules class names are exported, and named exports are enabled for CSS Modules by default.
+
+You can tune CSS Modules behavior with parser and generator options:
+
+```js displayName="webpack.config.js"
+export default {
+  experiments: {
+    css: true,
+  },
+  module: {
+    parser: {
+      'css/module': {
+        namedExports: true,
+      },
+    },
+    generator: {
+      'css/module': {
+        exportsConvention: 'camel-case-only',
+        localIdentName: '[uniqueName]-[id]-[local]',
+      },
+    },
+  },
+};
+```
+
+## Production builds
+
+With `experiments.css: true`, webpack performs native CSS extraction and applies content hashing to CSS assets in production builds.
+
+Compared with the classic setup:
+
+- Traditional approach: `css-loader` plus `mini-css-extract-plugin`.
+- Native approach: `experiments.css` with built-in extraction behavior.
+
+This reduces configuration and keeps the CSS pipeline closer to webpack's core features.
+
+## Experimental status and known limitations
+
+Because `experiments.css` is explicitly experimental, treat it as opt-in and test carefully before rolling it out widely.
+
+Keep the following points in mind:
+
+- APIs and behavior may still evolve before they become the default in webpack v6.
+- Some loader-specific options are not part of native CSS behavior (for example, loader-specific filters).
+- If your project relies on advanced loader chains, validate each part before migrating fully.
+
+## Migration guide
+
+If you currently rely on `css-loader`, `mini-css-extract-plugin`, and `style-loader`, migrate in small steps.
+
+### 1. Start from a classic setup
+
+```js displayName="webpack.config.js"
+import MiniCssExtractPlugin from 'mini-css-extract-plugin';
+
+export default {
+  module: {
+    rules: [
+      {
+        test: /\.css$/i,
+        use: [MiniCssExtractPlugin.loader, 'css-loader'],
+      },
+    ],
+  },
+  plugins: [new MiniCssExtractPlugin()],
+};
+```
+
+### 2. Switch to native CSS
+
+```js displayName="webpack.config.js"
+export default {
+  experiments: {
+    css: true,
+  },
+};
+```
+
+### 3. Migrate `css-loader` options first
+
+Most CSS Modules-related options should move to the native parser and generator configuration.
+
+```js displayName="webpack.config.js"
+export default {
+  experiments: {
+    css: true,
+  },
+  module: {
+    parser: {
+      css: {
+        import: true,
+        url: true,
+      },
+      'css/module': {
+        namedExports: true,
+      },
+    },
+    generator: {
+      'css/module': {
+        exportsConvention: 'camel-case-only',
+        localIdentName: '[local]-[hash:base64:6]',
+      },
+    },
+  },
+};
+```
+
+Notes:
+
+- `import` and `url` are native parser switches for CSS handling.
+- `namedExports` controls CSS Modules export behavior.
+- `exportsConvention` and `localIdentName` shape how class names are exported and named.
+- `localIdentName` supports hash placeholders (for example, `[hash:base64:6]`); you can tune hashing globally with [`output.hashFunction`](#TODO[/configuration/output/#outputhashfunction]), [`output.hashDigest`](#TODO[/configuration/output/#outputhashdigest]), [`output.hashDigestLength`](#TODO[/configuration/output/#outputhashdigestlength]), and [`output.hashSalt`](#TODO[/configuration/output/#outputhashsalt]).
+- `css-loader` filter-style options have no direct equivalent; use webpack mechanisms such as `IgnorePlugin` when you need them.
+
+### 4. Replace `mini-css-extract-plugin`
+
+When `experiments.css` is enabled, webpack handles native CSS extraction and content hashing for CSS output files, so you can drop both `mini-css-extract-plugin` and `css-loader` from this basic setup.
+
+```diff displayName="webpack.config.js"
+-import MiniCssExtractPlugin from "mini-css-extract-plugin";
+-
+ export default {
++  experiments: {
++    css: true,
++  },
+-  plugins: [new MiniCssExtractPlugin()],
+ };
+```
+
+You can remove:
+
+- the CSS loader chain (including `css-loader`) from `module.rules`, and
+- the `new MiniCssExtractPlugin()` plugin instance.
+
+### 5. Replace `style-loader` with `exportType: "style"`
+
+If you used `style-loader` for runtime style injection, keep `css/auto`, use the module naming convention (`.module.css` or `.modules.css`), and set `exportType: "style"`:
+
+```js displayName="webpack.config.js"
+export default {
+  experiments: {
+    css: true,
+  },
+  module: {
+    rules: [
+      {
+        test: /\.css$/i,
+        type: 'css/auto',
+        parser: {
+          exportType: 'style',
+        },
+      },
+    ],
+  },
+};
+```
+
+This mode injects a `<style>` element from the webpack runtime and covers the typical `style-loader` use case.
+
+If you cannot rename files to the CSS Modules naming convention, you can use `type: "css/module"` directly for the relevant rule.
+
+### 6. Keep imports unchanged
+
+Your JavaScript imports can stay the same:
+
+```js
+import './styles.css';
+import * as styles from './button.module.css';
+```
+
+### 7. Validate output in development and production
+
+Verify that:
+
+- styles are applied correctly in development,
+- CSS files are emitted for production, and
+- CSS Modules exports match your existing usage.
diff --git a/pages/guides/modern-web/progressive-web-application.md b/pages/guides/modern-web/progressive-web-application.md
new file mode 100644
index 00000000..6a2656dd
--- /dev/null
+++ b/pages/guides/modern-web/progressive-web-application.md
@@ -0,0 +1,139 @@
+---
+authors: johnnyreilly,chenxsan,EugeneHlushko,benschac,aholzner,avivkeller
+---
+
+# Progressive Web Application
+
+> [!TIP]
+> This guide builds on the code examples from the [Output Management](#TODO[/guides/output-management]) guide.
+
+Progressive Web Applications (PWAs) are web apps that deliver an experience similar to native applications. Many things can contribute to this, but the most significant is an app's ability to function while **offline**. This is achieved with a web technology called [Service Workers](https://developers.google.com/web/fundamentals/primers/service-workers/).
+
+This section focuses on adding an offline experience to our app. We'll do that with a Google project called [Workbox](https://github.com/GoogleChrome/workbox), which provides tools that make offline support easier to set up.
+
+## We don't work offline now
+
+So far, we've viewed our output by going directly to the local filesystem. In reality, though, a user accesses a web app over a network: their browser talks to a **server** that serves up the required assets (for example, `.html`, `.js`, and `.css` files).
+
+Let's test the current experience using a server with more basic features. We'll use the [http-server](https://www.npmjs.com/package/http-server) package: run `npm install http-server --save-dev`. We'll also add a `start` script to the `scripts` section of our `package.json`:
+
+```diff displayName="package.json"
+{
+  ...
+  "scripts": {
+-    "build": "webpack"
++    "build": "webpack",
++    "start": "http-server dist"
+  },
+  ...
+}
+```
+
+Note: the [webpack DevServer](#TODO[/configuration/dev-server/]) writes to memory by default. We'll need to enable the [`devServer.devMiddleware.writeToDisk`](#TODO[/configuration/dev-server/#devserverdevmiddleware]) option so that http-server can serve files from the `./dist` directory.
+
+If you haven't already, run `npm run build` to build your project. Then run `npm start`. This should produce output like the following:
+
+```bash
+> http-server dist
+
+Starting up http-server, serving dist
+Available on:
+  http://xx.x.x.x:8080
+  http://127.0.0.1:8080
+  http://xxx.xxx.x.x:8080
+Hit CTRL-C to stop the server
+```
+
+Open your browser to `http://localhost:8080` (that is, `http://127.0.0.1`) and you should see your webpack application served from the `dist` directory. If you stop the server and refresh, the application is no longer available.
+
+This is what we want to change. By the end of this module, we should be able to stop the server, refresh, and still see our application.
+
+## Adding Workbox
+
+Let's add the Workbox webpack plugin and adjust `webpack.config.js`:
+
+```bash
+npm install workbox-webpack-plugin --save-dev
+```
+
+```diff displayName="webpack.config.js"
+  import path from "node:path";
+  import { fileURLToPath } from 'node:url';
+  import HtmlWebpackPlugin from "html-webpack-plugin";
++ import WorkboxPlugin from "workbox-webpack-plugin";
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: {
+      app: './src/index.js',
+      print: './src/print.js',
+    },
+    plugins: [
+      new HtmlWebpackPlugin({
+-       title: 'Output Management',
++       title: 'Progressive Web Application',
+      }),
++     new WorkboxPlugin.GenerateSW({
++       // these options encourage the ServiceWorkers to get in there fast
++       // and not allow any straggling "old" SWs to hang around
++       clientsClaim: true,
++       skipWaiting: true,
++     }),
+    ],
+    output: {
+      filename: '[name].bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+      clean: true,
+    },
+  };
+```
+
+With that in place, let's see what happens when we run `npm run build`:
+
+```bash
+...
+                  Asset       Size  Chunks                    Chunk Names
+          app.bundle.js     545 kB    0, 1  [emitted]  [big]  app
+        print.bundle.js    2.74 kB       1  [emitted]         print
+             index.html  254 bytes          [emitted]
+precache-manifest.b5ca1c555e832d6fbf9462efd29d27eb.js  268 bytes          [emitted]
+      service-worker.js       1 kB          [emitted]
+...
+```
+
+As you can see, we now have two extra files: `service-worker.js` and the more verbose `precache-manifest.b5ca1c555e832d6fbf9462efd29d27eb.js`. `service-worker.js` is the Service Worker file, and `precache-manifest.b5ca1c555e832d6fbf9462efd29d27eb.js` is a file that `service-worker.js` requires in order to run. Your own generated files will likely differ, but you should have a `service-worker.js` file.
+
+We've now reached the happy point of having produced a Service Worker. What's next?
+
+## Registering our Service Worker
+
+Let's let our Service Worker come out and play by registering it. We'll do that by adding the registration code below:
+
+```diff displayName="index.js"
+  import _ from 'lodash';
+  import printMe from './print.js';
+
++ if ('serviceWorker' in navigator) {
++   window.addEventListener('load', () => {
++     navigator.serviceWorker.register('/service-worker.js').then(registration => {
++       console.log('SW registered: ', registration);
++     }).catch(registrationError => {
++       console.log('SW registration failed: ', registrationError);
++     });
++   });
++ }
+```
+
+Run `npm run build` once more to build a version of the app that includes the registration code. Then serve it with `npm start`. Navigate to `http://localhost:8080` and look at the console. Somewhere in there you should see:
+
+```bash
+SW registered
+```
+
+Now to test it: stop your server and refresh your page. If your browser supports Service Workers, you should still be looking at your application. This time, however, it has been served by your Service Worker and **not** by the server.
+
+## Conclusion
+
+You've built an offline app using the Workbox project, beginning the journey of turning your web app into a PWA. You may now want to take things further. A good resource to help you do that can be found [here](https://web.dev/progressive-web-apps/).
diff --git a/pages/guides/modern-web/web-workers.md b/pages/guides/modern-web/web-workers.md
new file mode 100644
index 00000000..0c4d4ff6
--- /dev/null
+++ b/pages/guides/modern-web/web-workers.md
@@ -0,0 +1,119 @@
+---
+authors: chenxsan,avivkeller
+---
+
+# Web Workers
+
+As of webpack 5, you can use [Web Workers](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers) without [`worker-loader`](https://github.com/webpack-contrib/worker-loader).
+
+## Syntax
+
+```js
+new Worker(new URL('./worker.js', import.meta.url));
+```
+
+```js
+// or customize the chunk name with magic comments
+// see https://webpack.js.org/api/module-methods/#magic-comments
+new Worker(
+  /* webpackChunkName: "foo-worker" */ new URL('./worker.js', import.meta.url)
+);
+```
+
+This syntax was chosen so that the code can run without a bundler; it's also available in native ECMAScript modules in the browser.
+
+Note that while the [`Worker` API](https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker) suggests the `Worker` constructor accepts a string representing the URL of the script, in webpack 5 you can only use a `URL` instead.
+
+Available in webpack 5.105.0+.
+
+When you use `new Worker()`, webpack can resolve worker modules by the export condition names defined in the package's `exports` field. This allows packages to provide worker-specific versions of modules automatically.
+
+```json displayName="package.json (in a dependency package)"
+{
+  "name": "my-package",
+  "exports": {
+    ".": {
+      "worker": "./index.worker.js",
+      "default": "./index.js"
+    }
+  }
+}
+```
+
+When you import this package inside a worker context:
+
+```js
+// Inside a worker file
+import { someFunction } from 'my-package';
+```
+
+webpack automatically resolves to `index.worker.js` when the module is used in a worker context, without requiring any additional configuration.
+
+> [!WARNING]
+> Using a variable in the `Worker` constructor is not supported by webpack. For example, the following code will not work: `const url = new URL('./path/to/worker.ts', import.meta.url); const worker = new Worker(url);`. This is because webpack cannot analyze the syntax statically. Keep this limitation in mind when using `Worker` syntax with webpack.
+
+## Example
+
+```js displayName="src/index.js"
+const worker = new Worker(new URL('./deep-thought.js', import.meta.url));
+worker.postMessage({
+  question:
+    'The Answer to the Ultimate Question of Life, The Universe, and Everything.',
+});
+worker.onmessage = ({ data: { answer } }) => {
+  console.log(answer);
+};
+```
+
+```js displayName="src/deep-thought.js"
+globalThis.onmessage = ({ data: { question } }) => {
+  self.postMessage({
+    answer: 42,
+  });
+};
+```
+
+## Set a public path from a variable
+
+When you set `__webpack_public_path__` from a variable and use `publicPath` equal to `auto`, worker chunks get a separate runtime, and the webpack runtime sets `publicPath` to an automatically calculated public path — which is probably not what you expect.
+
+To work around this, set `__webpack_public_path__` from within the worker code. Here is an example:
+
+```js displayName="worker.js"
+globalThis.onmessage = ({ data: { publicPath, ...otherData } }) => {
+  if (publicPath) {
+    __webpack_public_path__ = publicPath;
+  }
+
+  // rest of the worker code
+};
+```
+
+```js displayName="app.js"
+const worker = new Worker(new URL('./worker.js', import.meta.url));
+
+worker.postMessage({ publicPath: globalThis.__MY_GLOBAL_PUBLIC_PATH_VAR__ });
+```
+
+**When to use this:**
+
+This pattern is only required when a worker needs to load additional chunks and the asset base URL is determined at runtime (for example, when using a CDN or a multi-domain deployment).
+
+Since workers run in an isolated global scope, the automatically detected public path may differ from the one used by the main thread. In such cases, the public path (`__webpack_public_path__`) must be passed explicitly to the worker and set inside the worker runtime.
+
+> [!NOTE]
+> This is an advanced use case. If your worker does not load additional chunks, or your assets are served from a static, same-origin path, you typically don't need to set `__webpack_public_path__` manually.
+
+## Node.js
+
+This section describes using Web Workers in a Node.js environment via the `worker_threads` module.
+
+Similar syntax is supported in Node.js (>= 12.17.0):
+
+```js
+import { Worker } from 'node:worker_threads';
+
+new Worker(new URL('./worker.js', import.meta.url));
+```
+
+Note that this is only available in ESM. `Worker` in CommonJS syntax is not supported by either webpack or Node.js.
diff --git a/pages/guides/modules-and-dependencies/dependency-management.md b/pages/guides/modules-and-dependencies/dependency-management.md
new file mode 100644
index 00000000..21a09830
--- /dev/null
+++ b/pages/guides/modules-and-dependencies/dependency-management.md
@@ -0,0 +1,143 @@
+---
+authors: ndelangen,chrisVillanueva,sokra,byzyk,AnayaDesign,ThierryRakotomanana,avivkeller
+---
+
+# Dependency Management
+
+## Dynamic expressions in `import()` or `require()`
+
+When a request contains an expression, webpack cannot determine the **exact** module at compile time, so it creates a context instead.
+
+For example, suppose you have the following folder structure, which includes a number of `.ejs` files:
+
+```text
+example_directory
+└── template/
+    ├── table.ejs
+    ├── table-row.ejs
+    └── directory/
+        └── another.ejs
+```
+
+Now consider what happens when webpack evaluates the following `import()` or `require()` call:
+
+```js
+import(`./template/${name}.ejs`);
+require(`./template/${name}.ejs`);
+```
+
+webpack parses the call and extracts the following information from it:
+
+```text
+Directory: ./template
+Regular expression: /^.*\.ejs$/
+```
+
+### Context module
+
+From this, webpack generates a context module. The context module references **every module in that directory** that can be required with a request matching the regular expression, and it includes a map that translates each request to a module id.
+
+Here is an example of such a map:
+
+```json
+{
+  "./table.ejs": 42,
+  "./table-row.ejs": 43,
+  "./directory/another.ejs": 44
+}
+```
+
+The context module also contains the runtime logic needed to look up modules in this map.
+
+As a result, dynamic calls are supported, but every matching module ends up included in the bundle.
+
+## `import.meta.webpackContext`
+
+`import.meta.webpackContext` is the ESM equivalent of `require.context`.
+
+```js
+import.meta.webpackContext(directory, {
+  recursive: true,
+  regExp: /^\.\/.*$/,
+  mode: 'sync',
+});
+```
+
+> [!WARNING]
+> The arguments passed to `import.meta.webpackContext` must be literals.
+
+## `require.context`
+
+You can create your own context with the `require.context()` function.
+
+It accepts a directory to search, a flag that indicates whether subdirectories should also be searched, and a regular expression to match files against.
+
+webpack scans the code for `require.context()` calls while building.
+
+The syntax is as follows:
+
+```js
+require.context(
+  directory,
+  (useSubdirectories = true),
+  (regExp = /^\.\/.*$/),
+  (mode = 'sync')
+);
+```
+
+Examples:
+
+```js
+require.context('./test', false, /\.test\.js$/);
+// A context with files from the test directory that can be required with a request ending in `.test.js`.
+```
+
+```js
+require.context('../', true, /\.stories\.js$/);
+// A context with all files in the parent folder and its descendant folders ending in `.stories.js`.
+```
+
+> [!WARNING]
+> The arguments passed to `require.context` must be literals.
+
+### Context module API
+
+A context module exports a (require) function that takes a single argument: the request.
+
+This exported function has three properties: `resolve`, `keys`, and `id`.
+
+- `resolve` is a function that returns the module id of the parsed request.
+- `keys` is a function that returns an array of every request the context module can handle.
+
+This is handy when you want to require all files in a directory, or all files matching a pattern. For example:
+
+```js
+function importAll(r) {
+  r.keys().forEach(r);
+}
+
+importAll(
+  import.meta.webpackContext('../components/', {
+    recursive: true,
+    regExp: /\.js$/,
+  })
+);
+```
+
+```js
+const cache = {};
+
+function importAll(r) {
+  for (const key of r.keys()) cache[key] = r(key);
+}
+
+importAll(
+  import.meta.webpackContext('../components/', {
+    recursive: true,
+    regExp: /\.js$/,
+  })
+);
+// At build time, cache will be populated with all required modules.
+```
+
+- `id` is the module id of the context module. This can be useful for `import.meta.webpackHot.accept` or `module.hot.accept`.
diff --git a/pages/guides/modules-and-dependencies/ecma-script-modules.md b/pages/guides/modules-and-dependencies/ecma-script-modules.md
new file mode 100644
index 00000000..f199dc37
--- /dev/null
+++ b/pages/guides/modules-and-dependencies/ecma-script-modules.md
@@ -0,0 +1,210 @@
+---
+authors: sokra,ryzrr,avivkeller
+---
+
+# ECMAScript Modules
+
+ECMAScript Modules (ESM) is a [specification](https://tc39.github.io/ecma262/#sec-modules) for using modules on the Web. It is supported by all modern browsers and is the recommended way to write modular code for the Web.
+
+webpack supports processing ECMAScript Modules in order to optimize them.
+
+## Exporting
+
+The `export` keyword lets you expose values from an ESM to other modules:
+
+```js
+export const CONSTANT = 42;
+
+export let variable = 42;
+// only reading is exposed
+// it's not possible to modify the variable from outside
+
+export function fun() {
+  console.log('fun');
+}
+
+export class C extends Super {
+  method() {
+    console.log('method');
+  }
+}
+
+let a, b, other;
+export { a, b, other as c };
+
+export default 1 + 2 + 3 + more();
+```
+
+## Importing
+
+The `import` keyword lets you obtain references to values from other modules within an ESM:
+
+```js
+// import "bindings" to exports from another module.
+// These bindings are live: the values are not copied,
+// so accessing "variable" reads the current value
+// in the imported module.
+import { CONSTANT, variable } from './module.js';
+
+// shortcut to import the "default" export
+import theDefaultValue from './module.js';
+
+// import the "namespace object" which contains all exports
+import * as module from './module.js';
+
+module.fun();
+```
+
+When importing a namespace object from an ECMAScript Module, webpack follows the ESM convention of setting `Symbol.toStringTag` to `"Module"` on the namespace object.
+
+## Flagging modules as ESM
+
+By default, webpack automatically detects whether a file is an ESM or uses a different module system.
+
+Node.js established a way to explicitly set the module type of files through a property in `package.json`. Setting `"type": "module"` forces all files below that `package.json` to be treated as ECMAScript Modules, while `"type": "commonjs"` forces them to be CommonJS Modules.
+
+```json
+{
+  "type": "module"
+}
+```
+
+In addition, files can declare their module type through the `.mjs` or `.cjs` extension. `.mjs` forces ESM, and `.cjs` forces CommonJS.
+
+In Data URIs, using the `text/javascript` or `application/javascript` MIME type also forces the module type to ESM.
+
+Beyond the module format itself, flagging modules as ESM also affects the resolving logic, the interop logic, and the symbols available in modules.
+
+## `import.meta` in ESM
+
+webpack exposes several `import.meta` properties for use in ESM:
+
+| Property                     | Description                                                                                            |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------ |
+| `import.meta.url`            | The URL of the current module file — use it for `new Worker()` or `new URL()`.                         |
+| `import.meta.webpack`        | The webpack major version number (e.g. `5`).                                                           |
+| `import.meta.webpackHot`     | Equivalent of `module.hot` — use it for HMR in ESM.                                                    |
+| `import.meta.webpackContext` | [ESM equivalent of `require.context`](#TODO[/guides/dependency-management/#importmetawebpackcontext]). |
+
+**Example — using `import.meta.url` for assets:**
+
+```js
+// Resolve a sibling file relative to the current module
+const iconUrl = new URL('./icon.png', import.meta.url);
+const img = document.createElement('img');
+img.src = iconUrl.href;
+```
+
+**Example — HMR in ESM:**
+
+```js
+if (import.meta.webpackHot) {
+  import.meta.webpackHot.accept('./module.js', () => {
+    // handle update
+  });
+}
+```
+
+## Top-level await
+
+In ESM, you can use `await` at the top level of a module, and webpack automatically treats the module as an async module. This has been enabled by default since 5.83.0; the `experiments.topLevelAwait` option itself was removed in 5.102.0, so it now simply works.
+
+> [!WARNING]
+> Avoid top-level await in your entry point when targeting the **browser**. It delays evaluation of the entire module graph. Prefer `import()` for deferred loading. For Node.js, Electron, or Web Worker targets, this restriction does not apply.
+
+```js
+// user.js (async ESM module)
+const response = await fetch('/api/user');
+
+export const user = await response.json();
+```
+
+```js
+// index.js — importing an async module works as expected
+import { user } from './user.js';
+
+console.log(user.name);
+```
+
+## Fully specified imports
+
+Imports in ESM are resolved more strictly. Following the Node.js convention, relative requests must include a file extension (such as `*.js` or `*.mjs`) when the file is flagged as ESM:
+
+```js
+// will fail — missing extension
+import { helper as missingExt } from './utils';
+
+// correct in ESM
+import { helper } from './utils.js';
+```
+
+> [!TIP]
+> Requests to packages, such as `import "lodash"`, are still supported.
+
+To disable this check (which is useful when migrating a large CommonJS codebase), you can use [`fullySpecified=false`](#TODO[/configuration/module/#resolvefullyspecified]):
+
+```js displayName="webpack.config.js"
+export default {
+  module: {
+    rules: [
+      {
+        test: /\.m?js/,
+        resolve: {
+          fullySpecified: false,
+        },
+      },
+    ],
+  },
+};
+```
+
+## CommonJS interop
+
+CommonJS syntax is not available in ESM: `require`, `module`, `exports`, `__filename`, and `__dirname`.
+
+When importing from a CommonJS module inside ESM, only the `default` export is available — that is, the entire `module.exports` object:
+
+```js
+// esm-consumer.js (ESM)
+import cjs from './cjs-module.js';
+// named imports from CJS don't work
+import { foo } from './cjs-module.js'; // undefined
+
+// cjs-module.js (CommonJS)
+module.exports = { foo: 1, bar: 2 };
+
+console.log(cjs.foo); // works — cjs is the whole exports object
+```
+
+This strict behavior applies when webpack treats the **imported** module as CommonJS. If that module itself uses ESM `export` syntax, webpack auto-detects it as ESM and named imports work normally. This commonly affects projects that mix `.js` files in a project that has `"type": "module"` set: webpack may treat some files as ESM while third-party packages in `node_modules` remain CommonJS.
+
+> [!TIP]
+> To get named exports from CommonJS modules, consider migrating to ESM or using [`@babel/plugin-transform-modules-commonjs`](https://babeljs.io/docs/babel-plugin-transform-modules-commonjs).
+
+## Common migration errors
+
+**`ReferenceError: require is not defined`**
+
+When a file is treated as ESM, the CommonJS globals (`require`, `module`, `exports`, `__filename`, and `__dirname`) are unavailable.
+
+_Fix_: Replace `require()` with `import` statements. For conditional or dynamic loading, use `import()`.
+
+---
+
+**`Must use import to load ES Module`** (Node.js) / **`SyntaxError: Cannot use import statement in a module`** (browser)
+
+This happens when a file using ESM `import`/`export` syntax is not flagged as ESM — either `"type": "module"` is missing from `package.json`, or the file uses a `.js` extension instead of `.mjs`.
+
+_Fix_: Add `"type": "module"` to your `package.json`, or rename the file to `.mjs`.
+
+---
+
+**`Module not found: Error: Can't resolve './utils'` (missing extension)**
+
+In ESM, relative imports must include the file extension. webpack follows the Node.js ESM convention here.
+
+_Fix_: Change `import { helper } from './utils'` to `import { helper } from './utils.js'`, or set [`fullySpecified: false`](#TODO[/configuration/module/#resolvefullyspecified]) in your webpack config to disable the check while migrating.
+
+## Further reading
+
+- [ECMAScript Modules in Node.js](https://nodejs.org/api/esm.html)
diff --git a/pages/guides/modules-and-dependencies/entry-advanced.md b/pages/guides/modules-and-dependencies/entry-advanced.md
new file mode 100644
index 00000000..30117a59
--- /dev/null
+++ b/pages/guides/modules-and-dependencies/entry-advanced.md
@@ -0,0 +1,71 @@
+---
+authors: EugeneHlushko,avivkeller
+---
+
+# Advanced entry
+
+## Multiple file types per entry
+
+When you use an array of values for [entry](#TODO[/configuration/entry-context/#entry]), you can supply different types of files to produce separate bundles for CSS, JavaScript, and other assets. This is useful in applications that don't `import` styles from JavaScript, such as pre-Single-Page applications or projects structured for other reasons.
+
+Consider an example. We have a PHP application with two page types: home and account. The home page has a different layout and JavaScript that isn't shared with the rest of the application (the account page). From our application files, we want to produce `home.js` and `home.css` for the home page, and `account.js` and `account.css` for the account page.
+
+```js displayName="home.js"
+console.log('home page type');
+```
+
+```scss displayName="home.scss"
+// home page individual styles
+```
+
+```js displayName="account.js"
+console.log('account page type');
+```
+
+```scss displayName="account.scss"
+// account page individual styles
+```
+
+As a best practice, we'll use [`MiniCssExtractPlugin`](#TODO[/plugins/mini-css-extract-plugin/]) in `production` mode for the CSS.
+
+```js displayName="webpack.config.js"
+import MiniCssExtractPlugin from 'mini-css-extract-plugin';
+
+export default {
+  mode: process.env.NODE_ENV,
+  entry: {
+    home: ['./home.js', './home.scss'],
+    account: ['./account.js', './account.scss'],
+  },
+  output: {
+    filename: '[name].js',
+  },
+  module: {
+    rules: [
+      {
+        test: /\.scss$/,
+        use: [
+          // fallback to style-loader in development
+          process.env.NODE_ENV !== 'production'
+            ? 'style-loader'
+            : MiniCssExtractPlugin.loader,
+          'css-loader',
+          'sass-loader',
+        ],
+      },
+    ],
+  },
+  plugins: [
+    new MiniCssExtractPlugin({
+      filename: '[name].css',
+    }),
+  ],
+};
+```
+
+Running webpack with the configuration above outputs into `./dist`, since we did not specify a different output path. The `./dist` directory will then contain four files:
+
+- `home.js`
+- `home.css`
+- `account.js`
+- `account.css`
diff --git a/pages/guides/modules-and-dependencies/package-exports.md b/pages/guides/modules-and-dependencies/package-exports.md
new file mode 100644
index 00000000..555cddeb
--- /dev/null
+++ b/pages/guides/modules-and-dependencies/package-exports.md
@@ -0,0 +1,603 @@
+---
+authors: sokra,avivkeller
+---
+
+# Package exports
+
+The `exports` field in a package's `package.json` declares which module should be used for module requests such as `import "package"` or `import "package/sub/path"`. It replaces the default behavior, which returns the `main` field (or `index.js`) for `"package"` and performs a filesystem lookup for `"package/sub/path"`.
+
+Once the `exports` field is specified, only the requests it lists are available. Any other request results in a `ModuleNotFound` error.
+
+## General syntax
+
+In general, the `exports` field should be an object whose properties each describe a subpath of the module request. For the examples above, you could use `"."` for `import "package"` and `"./sub/path"` for `import "package/sub/path"`.
+
+Properties ending with `/` forward requests with that prefix to the old filesystem lookup algorithm. For properties ending with `*`, the `*` can take any value, and any `*` in the property value is replaced with that captured value.
+
+For example:
+
+```json
+{
+  "exports": {
+    ".": "./main.js",
+    "./sub/path": "./secondary.js",
+    "./prefix/": "./directory/",
+    "./prefix/deep/": "./other-directory/",
+    "./other-prefix/*": "./yet-another/*/*.js"
+  }
+}
+```
+
+| Module request                      | Result                                           |
+| ----------------------------------- | ------------------------------------------------ |
+| `package`                           | `.../package/main.js`                            |
+| `package/sub/path`                  | `.../package/secondary.js`                       |
+| `package/prefix/some/file.js`       | `.../package/directory/some/file.js`             |
+| `package/prefix/deep/file.js`       | `.../package/other-directory/file.js`            |
+| `package/other-prefix/deep/file.js` | `.../package/yet-another/deep/file/deep/file.js` |
+| `package/main.js`                   | Error                                            |
+
+## Alternatives
+
+Instead of a single result, the package author may provide a list of results. The list is tried in order, and the first valid result is used.
+
+Note: only the first valid result is used, not all valid results.
+
+For example:
+
+```json
+{
+  "exports": {
+    "./things/": ["./good-things/", "./bad-things/"]
+  }
+}
+```
+
+Here, `package/things/apple` might be found in `.../package/good-things/apple` or in `.../package/bad-things/apple`.
+
+> [!WARNING]
+> As of version 5.94.0, webpack's behavior has been updated to align with Node.js. It now selects the first valid path without attempting further resolutions, and throws an error if the path cannot be resolved.
+
+For example, given this configuration:
+
+```json
+{
+  "exports": {
+    ".": ["-bad-specifier-", "./non-existent.js", "./existent.js"]
+  }
+}
+```
+
+webpack 5.94.0 and later throws an error because `non-existent.js` is not found, whereas the previous behavior would have resolved to `existent.js`.
+
+## Conditional syntax
+
+Rather than providing results directly in the `exports` field, the package author may let the module system choose one based on conditions about the environment.
+
+To do this, use an object that maps conditions to results. Conditions are evaluated in object order, conditions whose results are invalid are skipped, and conditions may be nested to express a logical AND. The last condition in the object may be the special `"default"` condition, which always matches.
+
+For example:
+
+```json
+{
+  "exports": {
+    ".": {
+      "red": "./stop.js",
+      "yellow": "./stop.js",
+      "green": {
+        "free": "./drive.js",
+        "default": "./wait.js"
+      },
+      "default": "./drive-carefully.js"
+    }
+  }
+}
+```
+
+This translates to something like:
+
+```ts
+if (red && valid('./stop.js')) return './stop.js';
+if (yellow && valid('./stop.js')) return './stop.js';
+if (green) {
+  if (free && valid('./drive.js')) return './drive.js';
+  if (valid('./wait.js')) return './wait.js';
+}
+if (valid('./drive-carefully.js')) return './drive-carefully.js';
+throw new ModuleNotFoundError();
+```
+
+The available conditions vary depending on the module system and tool used.
+
+## Abbreviation
+
+When only a single entry (`"."`) into the package is needed, you can omit the `{ ".": ... }` object nesting:
+
+```json
+{
+  "exports": "./index.mjs"
+}
+```
+
+```json
+{
+  "exports": {
+    "red": "./stop.js",
+    "green": "./drive.js"
+  }
+}
+```
+
+## Notes about ordering
+
+In an object whose keys are conditions, the order of properties matters. Conditions are handled in the order they're specified.
+
+For example, `{ "red": "./stop.js", "green": "./drive.js" }` is not equivalent to `{ "green": "./drive.js", "red": "./stop.js" }`. When both the `red` and `green` conditions are set, the first property wins.
+
+In an object whose keys are subpaths, the order of properties is not significant. More specific paths are preferred over less specific ones.
+
+For example, `{ "./a/": "./x/", "./a/b/": "./y/", "./a/b/c": "./z" }` is equivalent to `{ "./a/b/c": "./z", "./a/b/": "./y/", "./a/": "./x/" }`. The order is always `./a/b/c` > `./a/b/` > `./a/`.
+
+The `exports` field takes precedence over other package entry fields such as `main`, `module`, `browser`, or custom ones.
+
+## Support
+
+| Feature                                | Supported by                                                                           |
+| -------------------------------------- | -------------------------------------------------------------------------------------- |
+| `"."` property                         | Node.js, webpack, rollup, esinstall, wmr                                               |
+| normal property                        | Node.js, webpack, rollup, esinstall, wmr                                               |
+| property ending with `/`               | ~~Node.js<sup>(1)</sup>~~, webpack, rollup, esinstall<sup>(2)</sup>, wmr<sup>(3)</sup> |
+| property ending with `*`               | Node.js, webpack, rollup, esinstall                                                    |
+| Alternatives                           | Node.js, webpack, rollup, <strike>esinstall</strike><sup>(4)</sup>                     |
+| Abbreviation only path                 | Node.js, webpack, rollup, esinstall, wmr                                               |
+| Abbreviation only conditions           | Node.js, webpack, rollup, esinstall, wmr                                               |
+| Conditional syntax                     | Node.js, webpack, rollup, esinstall, wmr                                               |
+| Nested conditional syntax              | Node.js, webpack, rollup, wmr<sup>(5)</sup>                                            |
+| Conditions Order                       | Node.js, webpack, rollup, wmr<sup>(6)</sup>                                            |
+| `"default"` condition                  | Node.js, webpack, rollup, esinstall, wmr                                               |
+| Path Order                             | Node.js, webpack, rollup                                                               |
+| Error when not mapped                  | Node.js, webpack, rollup, esinstall, wmr<sup>(7)</sup>                                 |
+| Error when mixing conditions and paths | Node.js, webpack, rollup                                                               |
+
+(1) Removed in Node.js 17. Use `*` instead.
+
+(2) `"./"` is intentionally ignored as a key.
+
+(3) The property value is ignored and the property key is used as the target. This effectively only allows mappings where the key and value are identical.
+
+(4) The syntax is supported, but the first entry is always used, which makes it unusable for any practical case.
+
+(5) Fallback to alternative sibling parent conditions is handled incorrectly.
+
+(6) For the `require` condition, object order is handled incorrectly. This is intentional, as wmr does not distinguish between referencing syntaxes.
+
+(7) When using the `"exports": "./file.js"` abbreviation, any request (for example, `package/not-existing`) resolves to that file. Without the abbreviation, direct file access (for example, `package/file.js`) will not lead to an error.
+
+## Conditions
+
+### Reference syntax
+
+One of these conditions is set depending on the syntax used to reference the module:
+
+| Condition | Description                                                         | Supported by                                                         |
+| --------- | ------------------------------------------------------------------- | -------------------------------------------------------------------- |
+| `import`  | Request is issued from ESM syntax or similar.                       | Node.js, webpack, rollup, esinstall<sup>(1)</sup>, wmr<sup>(1)</sup> |
+| `require` | Request is issued from CommonJS/AMD syntax or similar.              | Node.js, webpack, rollup, esinstall<sup>(1)</sup>, wmr<sup>(1)</sup> |
+| `style`   | Request is issued from a stylesheet reference.                      |                                                                      |
+| `sass`    | Request is issued from a Sass stylesheet reference.                 |                                                                      |
+| `asset`   | Request is issued from an asset reference.                          |                                                                      |
+| `script`  | Request is issued from a normal script tag without a module system. |                                                                      |
+
+These conditions may also be set additionally:
+
+| Condition   | Description                                                                                                   | Supported by         |
+| ----------- | ------------------------------------------------------------------------------------------------------------- | -------------------- |
+| `module`    | All module syntax that allows referencing JavaScript supports ESM (only combined with `import` or `require`). | webpack, rollup, wmr |
+| `esmodules` | Always set by supported tools.                                                                                | wmr                  |
+| `types`     | Request is issued from TypeScript that is interested in type declarations.                                    |                      |
+
+(1) `import` and `require` are both set independently of the referencing syntax. `require` always has lower priority.
+
+#### `import`
+
+The following syntax sets the `import` condition:
+
+- ESM `import` declarations in ESM
+- JS `import()` expressions
+- HTML `<script type="module">`
+- HTML `<link rel="preload/prefetch">`
+- JS `new Worker(..., { type: "module" })`
+- WASM `import` section
+- ESM HMR (webpack) `import.hot.accept/decline([...])`
+- JS `Worklet.addModule`
+- Using JavaScript as an entrypoint
+
+#### `require`
+
+The following syntax sets the `require` condition:
+
+- CommonJS `require(...)`
+- AMD `define()`
+- AMD `require([...])`
+- CommonJS `require.resolve()`
+- CommonJS (webpack) `require.ensure([...])`
+- CommonJS (webpack) `require.context`
+- CommonJS HMR (webpack) `module.hot.accept/decline([...])`
+- HTML `<script src="...">`
+
+#### `style`
+
+The following syntax sets the `style` condition:
+
+- CSS `@import`
+- HTML `<link rel="stylesheet">`
+
+#### `asset`
+
+The following syntax sets the `asset` condition:
+
+- CSS `url()`
+- ESM `new URL(..., import.meta.url)`
+- HTML `<img src="...">`
+
+#### `script`
+
+The following syntax sets the `script` condition:
+
+- HTML `<script src="...">`
+
+The `script` condition should be set only when no module system is supported. When the script is preprocessed by a system that supports CommonJS, it should set `require` instead.
+
+Use this condition when looking for a JavaScript file that can be injected as a script tag into an HTML page without additional preprocessing.
+
+### Optimizations
+
+The following conditions are set for various optimizations:
+
+| Condition     | Description                                                    | Supported by |
+| ------------- | -------------------------------------------------------------- | ------------ |
+| `production`  | In a production environment. No devtooling should be included. | webpack      |
+| `development` | In a development environment. Devtooling should be included.   | webpack      |
+
+Note: since `production` and `development` are not supported everywhere, make no assumptions when neither is set.
+
+### Target environment
+
+The following conditions are set depending on the target environment:
+
+| Condition      | Description                                   | Supported by                        |
+| -------------- | --------------------------------------------- | ----------------------------------- |
+| `browser`      | Code will run in a browser.                   | webpack, esinstall, wmr             |
+| `electron`     | Code will run in Electron.<sup>(1)</sup>      | webpack                             |
+| `worker`       | Code will run in a (Web)Worker.<sup>(1)</sup> | webpack                             |
+| `worklet`      | Code will run in a Worklet.<sup>(1)</sup>     |                                     |
+| `node`         | Code will run in Node.js.                     | Node.js, webpack, wmr<sup>(2)</sup> |
+| `deno`         | Code will run in Deno.                        |                                     |
+| `react-native` | Code will run in React Native.                |                                     |
+
+(1) `electron`, `worker`, and `worklet` come combined with either `node` or `browser`, depending on the context.
+
+(2) This is set for the browser target environment.
+
+Since there are multiple versions of each environment, the following guidelines apply:
+
+- `node`: See the `engines` field for compatibility.
+- `browser`: Compatible with the current spec and stage 4 proposals at the time the package is published. Polyfilling or transpiling must be handled on the consumer side.
+  - Features that cannot be polyfilled or transpiled should be used carefully, as they limit possible usage.
+- `deno`: TBD
+- `react-native`: TBD
+
+### Conditions: preprocessor and runtimes
+
+The following conditions are set depending on which tool preprocesses the source code:
+
+| Condition | Description           | Supported by |
+| --------- | --------------------- | ------------ |
+| `webpack` | Processed by webpack. | webpack      |
+
+Unfortunately, there is no `node-js` condition for Node.js as a runtime. Such a condition would simplify creating exceptions for Node.js.
+
+### Conditions: custom
+
+The following tools support custom conditions:
+
+| Tool      | Supported | Notes                                                                                                          |
+| --------- | --------- | -------------------------------------------------------------------------------------------------------------- |
+| Node.js   | yes       | Use the [`--conditions`](https://nodejs.org/api/cli.html#cli_c_condition_conditions_condition) CLI argument.   |
+| webpack   | yes       | Use the [`resolve.conditionNames`](#TODO[/configuration/resolve/#resolveconditionnames]) configuration option. |
+| rollup    | yes       | Use the `exportConditions` option for `@rollup/plugin-node-resolve`.                                           |
+| esinstall | no        |                                                                                                                |
+| wmr       | no        |                                                                                                                |
+
+For custom conditions, the following naming scheme is recommended:
+
+`<company-name>:<condition-name>`
+
+Examples: `example-corp:beta`, `google:internal`.
+
+## Common patterns
+
+All patterns below are explained with a single `"."` entry into the package, but they can be extended to multiple entries by repeating the pattern for each one.
+
+Treat these patterns as a guide, not a strict ruleset. Adapt them to each package as needed.
+
+These patterns are based on the following goals and assumptions:
+
+- Packages rot.
+  - We assume that at some point packages are no longer maintained but continue to be used.
+  - `exports` should be written with fallbacks for unknown future cases. The `default` condition is well suited for this.
+  - Because the future is unknown, we assume an environment similar to browsers and a module system similar to ESM.
+- Not all conditions are supported by every tool.
+  - Fallbacks should handle these cases.
+  - We assume the following fallbacks generally make sense:
+    - ESM > CommonJS
+    - Production > Development
+    - Browser > Node.js
+
+Depending on a package's intent, something else may make sense, in which case the patterns should be adapted. For example, for a command-line tool, a browser-like future and fallback doesn't make much sense; Node.js-like environments and fallbacks should be used instead.
+
+For complex cases, multiple patterns must be combined by nesting these conditions.
+
+### Target-environment-independent packages
+
+These patterns make sense for packages that do not use environment-specific APIs.
+
+#### Providing only an ESM version
+
+```json
+{
+  "type": "module",
+  "exports": "./index.js"
+}
+```
+
+Note: providing only ESM comes with restrictions for Node.js. Such a package only works in Node.js >= 14 and only when using `import`. It won't work with `require()`.
+
+#### Providing CommonJS and ESM versions (stateless)
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "node": {
+      "module": "./index.js",
+      "require": "./index.cjs"
+    },
+    "default": "./index.js"
+  }
+}
+```
+
+Most tools get the ESM version. Node.js is the exception: it gets a CommonJS version when using `require()`. This leads to two instances of the package when it is referenced with both `require()` and `import`, but that's harmless because the package has no state.
+
+The `module` condition is used as an optimization when preprocessing Node-targeted code with a tool that supports ESM for `require()` (such as a bundler that bundles for Node.js). For such a tool, the exception is skipped. This is technically optional, but bundlers would otherwise include the package source code twice.
+
+You can also use the stateless pattern if you isolate your package state in JSON files. JSON is consumable from both CommonJS and ESM without polluting the graph with the other module system.
+
+Note that "stateless" here also means class instances are not tested with `instanceof`, since there can be two different classes because of the double module instantiation.
+
+#### Providing CommonJS and ESM versions (stateful)
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "node": {
+      "module": "./index.js",
+      "import": "./wrapper.js",
+      "require": "./index.cjs"
+    },
+    "default": "./index.js"
+  }
+}
+```
+
+```js
+// wrapper.js
+import cjs from './index.cjs';
+
+export const A = cjs.A;
+export const B = cjs.B;
+```
+
+In a stateful package, we must ensure the package is never instantiated twice. This isn't a problem for most tools, but Node.js is again the exception. For Node.js, we always use the CommonJS version and expose named exports in ESM through an ESM wrapper.
+
+We use the `module` condition as an optimization here as well.
+
+#### Providing only a CommonJS version
+
+```json
+{
+  "type": "commonjs",
+  "exports": "./index.js"
+}
+```
+
+Specifying `"type": "commonjs"` helps tools statically detect CommonJS files.
+
+#### Providing a bundled script version for direct browser consumption
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "script": "./dist-bundle.js",
+    "default": "./index.js"
+  }
+}
+```
+
+Note that despite `"type": "module"` and the `.js` extension on `dist-bundle.js`, this file is not in ESM format. It should use globals so it can be consumed directly as a script tag.
+
+### Providing devtools or production optimizations
+
+These patterns make sense when a package ships two versions, one for development and one for production. For example, the development version might include extra code for better error messages or additional warnings.
+
+#### Without Node.js runtime detection
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "development": "./index-with-devtools.js",
+    "default": "./index-optimized.js"
+  }
+}
+```
+
+When the `development` condition is supported, we use the development-enhanced version. Otherwise, in production or when the mode is unknown, we use the optimized version.
+
+#### With Node.js runtime detection
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "development": "./index-with-devtools.js",
+    "production": "./index-optimized.js",
+    "node": "./wrapper-process-env.cjs",
+    "default": "./index-optimized.js"
+  }
+}
+```
+
+```js displayName="wrapper-process-env.cjs"
+module.exports =
+  process.env.NODE_ENV !== 'development'
+    ? require('./index-optimized.cjs')
+    : require('./index-with-devtools.cjs');
+```
+
+We prefer static detection of production/development mode via the `production` or `development` condition.
+
+Node.js can detect production/development mode at runtime via `process.env.NODE_ENV`, so we use that as a fallback in Node.js. Synchronously importing ESM conditionally is not possible, and we don't want to load the package twice, so we use CommonJS for the runtime detection.
+
+When the mode cannot be detected, we fall back to the production version.
+
+### Providing different versions depending on target environment
+
+Choose a fallback environment that makes sense for the package and supports future environments. In general, assume a browser-like environment.
+
+#### Providing Node.js, Web Worker, and browser versions
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "node": "./index-node.js",
+    "worker": "./index-worker.js",
+    "default": "./index.js"
+  }
+}
+```
+
+#### Providing Node.js, browser, and Electron versions
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "electron": {
+      "node": "./index-electron-node.js",
+      "default": "./index-electron.js"
+    },
+    "node": "./index-node.js",
+    "default": "./index.js"
+  }
+}
+```
+
+### Combining patterns
+
+#### Example 1
+
+This is an example of a package that has optimizations for production and development usage with runtime detection for `process.env`, and that also ships CommonJS and ESM versions:
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "node": {
+      "development": {
+        "module": "./index-with-devtools.js",
+        "import": "./wrapper-with-devtools.js",
+        "require": "./index-with-devtools.cjs"
+      },
+      "production": {
+        "module": "./index-optimized.js",
+        "import": "./wrapper-optimized.js",
+        "require": "./index-optimized.cjs"
+      },
+      "default": "./wrapper-process-env.cjs"
+    },
+    "development": "./index-with-devtools.js",
+    "production": "./index-optimized.js",
+    "default": "./index-optimized.js"
+  }
+}
+```
+
+#### Example 2
+
+This is an example of a package that supports Node.js, the browser, and Electron, has optimizations for production and development usage with runtime detection for `process.env`, and also ships CommonJS and ESM versions:
+
+```json
+{
+  "type": "module",
+  "exports": {
+    "electron": {
+      "node": {
+        "development": {
+          "module": "./index-electron-node-with-devtools.js",
+          "import": "./wrapper-electron-node-with-devtools.js",
+          "require": "./index-electron-node-with-devtools.cjs"
+        },
+        "production": {
+          "module": "./index-electron-node-optimized.js",
+          "import": "./wrapper-electron-node-optimized.js",
+          "require": "./index-electron-node-optimized.cjs"
+        },
+        "default": "./wrapper-electron-node-process-env.cjs"
+      },
+      "development": "./index-electron-with-devtools.js",
+      "production": "./index-electron-optimized.js",
+      "default": "./index-electron-optimized.js"
+    },
+    "node": {
+      "development": {
+        "module": "./index-node-with-devtools.js",
+        "import": "./wrapper-node-with-devtools.js",
+        "require": "./index-node-with-devtools.cjs"
+      },
+      "production": {
+        "module": "./index-node-optimized.js",
+        "import": "./wrapper-node-optimized.js",
+        "require": "./index-node-optimized.cjs"
+      },
+      "default": "./wrapper-node-process-env.cjs"
+    },
+    "development": "./index-with-devtools.js",
+    "production": "./index-optimized.js",
+    "default": "./index-optimized.js"
+  }
+}
+```
+
+It looks complex, yes. We were already able to reduce some complexity thanks to an assumption we can make: only `node` needs a CommonJS version and can detect production/development with `process.env`.
+
+## Guidelines
+
+- Avoid the `default` export. It's handled differently across tooling. Use only named exports.
+- Never provide different APIs or semantics for different conditions.
+- Write your source code as ESM and transpile to CJS with Babel, TypeScript, or a similar tool.
+- Use either `.cjs` or `"type": "commonjs"` in `package.json` to clearly mark source code as CommonJS. This makes it statically detectable whether CommonJS or ESM is used, which matters for tools that support only ESM and not CommonJS.
+- ESM used in packages supports the following request types:
+  - Module requests, pointing to other packages with a `package.json`.
+  - Relative requests, pointing to other files within the package.
+    - They must not point to files outside the package.
+  - `data:` URL requests.
+  - Other absolute or server-relative requests are not supported by default, though some tools or environments may support them.
+
+## Further reading
+
+- [Package entry points in Node.js](https://nodejs.org/api/packages.html#packages_package_entry_points)
diff --git a/pages/guides/modules-and-dependencies/shimming.md b/pages/guides/modules-and-dependencies/shimming.md
new file mode 100644
index 00000000..f3703cb6
--- /dev/null
+++ b/pages/guides/modules-and-dependencies/shimming.md
@@ -0,0 +1,461 @@
+---
+authors: pksjce,jhnns,simon04,jeremenichelli,svyandun,byzyk,EugeneHlushko,AnayaDesign,dhurlburtusa,plr108,NicolasLetellier,wizardofhogwarts,snitin315,chenxsan,avivkeller
+---
+
+# Shimming
+
+The webpack compiler can understand modules written as ES2015 modules, CommonJS, or AMD. However, some third-party libraries expect global dependencies (for example, `$` for jQuery). These libraries may also create globals that need to be exported. Such "broken modules" are one case where _shimming_ comes into play.
+
+> [!WARNING]
+> **We don't recommend using globals!** The whole concept behind webpack is to enable more modular front-end development. That means writing isolated modules that are well contained and do not rely on hidden dependencies (such as globals). Please use these features only when necessary.
+
+Another case where shimming is useful is when you want to [polyfill](https://en.wikipedia.org/wiki/Polyfill_%28programming%29) browser functionality to support more users. Here, you may want to deliver those polyfills only to the browsers that need patching (that is, load them on demand).
+
+The following article walks through both of these use cases.
+
+> [!TIP]
+> For simplicity, this guide builds on the examples from [Getting Started](#TODO[/guides/getting-started]). Make sure you're familiar with that setup before moving on.
+
+## Shimming globals
+
+Let's start with the first use case: shimming global variables. Before doing anything, let's take another look at our project:
+
+```diff displayName="project"
+webpack-demo
+ ├── package.json
+ ├── package-lock.json
+ ├── webpack.config.js
+ ├── /dist
+ │   └── index.html
+ ├── /src
+ │   └── index.js
+ └── /node_modules
+```
+
+Remember the `lodash` package we were using? For demonstration purposes, let's say we want to provide it as a global throughout our application instead. To do this, we can use `ProvidePlugin`.
+
+The [`ProvidePlugin`](#TODO[/plugins/provide-plugin]) makes a package available as a variable in every module compiled through webpack. If webpack sees that variable used, it includes the given package in the final bundle. Let's remove the `import` statement for `lodash` and provide it through the plugin instead:
+
+```diff displayName="src/index.js"
+-import _ from 'lodash';
+-
+ function component() {
+   const element = document.createElement('div');
+
+-  // Lodash, now imported by this script
+   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+```diff displayName="webpack.config.js"
+ import path from "node:path";
+ import { fileURLToPath } from 'url';
++import webpack from "webpack";
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'main.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
++  plugins: [
++    new webpack.ProvidePlugin({
++      _: 'lodash',
++    }),
++  ],
+ };
+```
+
+What we've essentially told webpack is this:
+
+> If you encounter at least one instance of the variable `_`, include the `lodash` package and provide it to the modules that need it.
+
+If we run a build, we should still see the same output:
+
+```bash
+$ npm run build
+
+..
+
+[webpack-cli] Compilation finished
+asset main.js 69.1 KiB [emitted] [minimized] (name: main) 1 related asset
+runtime modules 344 bytes 2 modules
+cacheable modules 530 KiB
+  ./src/index.js 191 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 2910 ms
+```
+
+We can also use `ProvidePlugin` to expose a single export of a module by configuring it with an "array path" (for example, `[module, child, ...children?]`). Let's imagine we only want to provide the `join` method from `lodash` wherever it's invoked:
+
+```diff displayName="src/index.js"
+ function component() {
+   const element = document.createElement('div');
+
+-  element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++  element.innerHTML = join(['Hello', 'webpack'], ' ');
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+```diff displayName="webpack.config.js"
+ import path from "node:path";
+ import webpack from "webpack";
+ import { fileURLToPath } from 'url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'main.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   plugins: [
+     new webpack.ProvidePlugin({
+-      _: 'lodash',
++      join: ['lodash', 'join'],
+     }),
+   ],
+ };
+```
+
+This pairs nicely with [Tree Shaking](#TODO[/guides/tree-shaking]), as the rest of the `lodash` library should get dropped.
+
+## Granular shimming
+
+Some legacy modules rely on `this` being the `window` object. Let's update our `index.js` so that's the case:
+
+```diff
+ function component() {
+   const element = document.createElement('div');
+
+   element.innerHTML = join(['Hello', 'webpack'], ' ');
+
++  // Assume we are in the context of `window`
++  this.alert("Hmmm, this probably isn't a great idea...");
++
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+This becomes a problem when the module runs in a CommonJS context, where `this` equals `module.exports`. In that case, you can override `this` using the [`imports-loader`](#TODO[/loaders/imports-loader/]):
+
+```diff displayName="webpack.config.js"
+ import path from "node:path";
+ import webpack from "webpack";
+ import { fileURLToPath } from 'url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'main.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
++  module: {
++    rules: [
++      {
++        test: import.meta.resolve('./src/index.js'),
++        use: 'imports-loader?wrapper=window',
++      },
++    ],
++  },
+   plugins: [
+     new webpack.ProvidePlugin({
+       join: ['lodash', 'join'],
+     }),
+   ],
+ };
+```
+
+## Global exports
+
+Let's say a library creates a global variable that it expects its consumers to use. We can add a small module to our setup to demonstrate this:
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
++ │   ├── globals.js
+  └── /node_modules
+```
+
+```js displayName="src/globals.js"
+const file = 'blah.txt';
+const helpers = {
+  test() {
+    console.log('test something');
+  },
+  parse() {
+    console.log('parse something');
+  },
+};
+```
+
+You'd likely never write code like this in your own source, but you may come across a dated library that contains something similar. In that case, we can use [`exports-loader`](#TODO[/loaders/exports-loader/]) to export that global variable as a normal module export. For instance, to export `file` as `file` and `helpers.parse` as `parse`:
+
+```diff displayName="webpack.config.js"
+ import path from "node:path";
+ import webpack from "webpack";
+ import { fileURLToPath } from 'url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     filename: 'main.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: import.meta.resolve('./src/index.js'),
+         use: 'imports-loader?wrapper=window',
+       },
++      {
++        test: import.meta.resolve('./src/globals.js'),
++        use:
++          'exports-loader?type=commonjs&exports=file,multiple|helpers.parse|parse',
++      },
+     ],
+   },
+   plugins: [
+     new webpack.ProvidePlugin({
+       join: ['lodash', 'join'],
+     }),
+   ],
+ };
+```
+
+Now, from within our entry script (`src/index.js`), we can use `const { file, parse } = require('./globals.js');` and everything should work smoothly.
+
+## Loading polyfills
+
+Almost everything we've discussed so far has dealt with handling legacy packages. Let's move on to our second topic: **polyfills**.
+
+There are many ways to load polyfills. For example, to include [`babel-polyfill`](https://babeljs.io/docs/en/babel-polyfill/) we might:
+
+```bash
+npm install --save babel-polyfill
+```
+
+and `import` it so it's included in our main bundle:
+
+```diff displayName="src/index.js"
++import 'babel-polyfill';
++
+ function component() {
+   const element = document.createElement('div');
+
+   element.innerHTML = join(['Hello', 'webpack'], ' ');
+
+   // Assume we are in the context of `window`
+   this.alert("Hmmm, this probably isn't a great idea...");
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+> [!TIP]
+> Note that we don't bind the `import` to a variable. This is because polyfills run on their own, before the rest of the code base, allowing us to assume certain native functionality exists.
+
+Note that this approach prioritizes correctness over bundle size. To be safe and robust, polyfills and shims must run **before all other code**, so they either need to load synchronously, or all app code needs to load after all polyfills and shims have loaded.
+
+There are many misconceptions in the community: that modern browsers "don't need" polyfills, or that polyfills and shims merely add missing features. In fact, they often _repair broken implementations_, even in the most modern browsers. The best practice therefore remains to load all polyfills and shims unconditionally and synchronously, despite the bundle-size cost this incurs.
+
+If you've mitigated these concerns and are willing to accept the risk of breakage, here's one way you might do it. Let's move our `import` to a new file and add the [`whatwg-fetch`](https://github.com/github/fetch) polyfill:
+
+```bash
+npm install --save whatwg-fetch
+```
+
+```diff displayName="src/index.js"
+-import 'babel-polyfill';
+-
+ function component() {
+   const element = document.createElement('div');
+
+   element.innerHTML = join(['Hello', 'webpack'], ' ');
+
+   // Assume we are in the context of `window`
+   this.alert("Hmmm, this probably isn't a great idea...");
+
+   return element;
+ }
+
+ document.body.appendChild(component());
+```
+
+```diff displayName="project"
+  webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
+  │   ├── globals.js
++ │   └── polyfills.js
+  └── /node_modules
+```
+
+```js displayName="src/polyfills.js"
+import 'babel-polyfill';
+import 'whatwg-fetch';
+```
+
+```diff displayName="webpack.config.js"
+ import path from "node:path";
+ import webpack from "webpack";
+ import { fileURLToPath } from 'url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+-  entry: './src/index.js',
++  entry: {
++    polyfills: './src/polyfills',
++    index: './src/index.js',
++  },
+   output: {
+-    filename: 'main.js',
++    filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+   module: {
+     rules: [
+       {
+         test: fileURLToPath(import.meta.resolve('./src/index.js')),
+         use: 'imports-loader?wrapper=window',
+       },
+       {
+         test: fileURLToPath(import.meta.resolve('./src/globals.js')),
+         use:
+           'exports-loader?type=commonjs&exports[]=file&exports[]=multiple|helpers.parse|parse',
+       },
+     ],
+   },
+   plugins: [
+     new webpack.ProvidePlugin({
+       join: ['lodash', 'join'],
+     }),
+   ],
+ };
+```
+
+With that in place, we can add logic to conditionally load our new `polyfills.bundle.js` file. How you make that decision depends on the technologies and browsers you need to support. We'll do some testing to determine whether our polyfills are needed:
+
+```diff displayName="dist/index.html"
+ <!DOCTYPE html>
+ <html>
+   <head>
+     <meta charset="utf-8" />
+     <title>Getting Started</title>
++    <script>
++      const modernBrowser = 'fetch' in window && 'assign' in Object;
++
++      if (!modernBrowser) {
++        const scriptElement = document.createElement('script');
++
++        scriptElement.async = false;
++        scriptElement.src = '/polyfills.bundle.js';
++        document.head.appendChild(scriptElement);
++      }
++    </script>
+   </head>
+   <body>
+-    <script src="main.js"></script>
++    <script src="index.bundle.js"></script>
+   </body>
+ </html>
+```
+
+Now we can `fetch` some data within our entry script:
+
+```diff displayName="src/index.js"
+ function component() {
+   const element = document.createElement('div');
+
+   element.innerHTML = join(['Hello', 'webpack'], ' ');
+
+   // Assume we are in the context of `window`
+   this.alert("Hmmm, this probably isn't a great idea...");
+
+   return element;
+ }
+
+ document.body.appendChild(component());
++
++fetch('https://jsonplaceholder.typicode.com/users')
++  .then((response) => response.json())
++  .then((json) => {
++    console.log(
++      "We retrieved some data! AND we're confident it will work on a variety of browser distributions."
++    );
++    console.log(json);
++  })
++  .catch((error) =>
++    console.error('Something went wrong when fetching this data: ', error)
++  );
+```
+
+If we run our build, another `polyfills.bundle.js` file will be emitted and everything should still run smoothly in the browser. This setup could likely be improved further, but it should give you a good idea of how to provide polyfills only to the users who actually need them.
+
+## Further optimizations
+
+The `babel-preset-env` package uses [browserslist](https://github.com/browserslist/browserslist) to transpile only what your browser matrix doesn't support. This preset comes with the [`useBuiltIns`](https://babeljs.io/docs/en/babel-preset-env#usebuiltins) option (`false` by default), which converts your global `babel-polyfill` import into a more granular, feature-by-feature `import` pattern:
+
+```js
+import 'core-js/modules/es7.string.pad-start';
+import 'core-js/modules/es7.string.pad-end';
+import 'core-js/modules/web.timers';
+import 'core-js/modules/web.immediate';
+import 'core-js/modules/web.dom.iterable';
+```
+
+See [the babel-preset-env documentation](https://babeljs.io/docs/en/babel-preset-env) for more information.
+
+## Node built-ins
+
+Node built-ins, such as `process`, can be polyfilled directly from your configuration file without any special loaders or plugins. See the [node configuration page](#TODO[/configuration/node]) for more information and examples.
+
+## Other utilities
+
+A few other tools can help when dealing with legacy modules.
+
+When a module has no AMD or CommonJS version and you want to include its `dist`, you can flag the module in [`noParse`](#TODO[/configuration/module/#modulenoparse]). This causes webpack to include the module without parsing it or resolving its `import` and `require()` statements. This practice can also improve build performance.
+
+> [!WARNING]
+> Any feature requiring the AST, such as `ProvidePlugin`, will not work.
+
+Finally, some modules support multiple [module styles](#TODO[/concepts/modules]) (for example, a combination of AMD, CommonJS, and legacy). In most of these cases, they first check for `define` and then use some quirky code to export properties. In these cases, it can help to force the CommonJS path by setting `additionalCode=var%20define%20=%20false;` via the [`imports-loader`](#TODO[/loaders/imports-loader/]).
+
+## Further reading
+
+- [Reward modern browser users script](https://medium.com/hackernoon/10-things-i-learned-making-the-fastest-site-in-the-world-18a0e1cdf4a7)
+- [`useBuiltIns` in babel-preset-env](https://babeljs.io/docs/en/babel-preset-env#usebuiltins)
diff --git a/pages/guides/optimization/build-performance.md b/pages/guides/optimization/build-performance.md
new file mode 100644
index 00000000..e6a771c3
--- /dev/null
+++ b/pages/guides/optimization/build-performance.md
@@ -0,0 +1,249 @@
+---
+authors: sokra,tbroadley,byzyk,madhavarshney,wizardofhogwarts,anikethsaha,Brennvo,avivkeller
+---
+
+# Build Performance
+
+This guide collects practical tips for improving the speed of your builds and compilations.
+
+## General
+
+The advice below applies whether you're running build scripts in [development](#TODO[/guides/development]) or [production](#TODO[/guides/production]).
+
+### Stay up to date
+
+Always use the latest version of webpack. Performance improvements land continuously, so newer releases tend to be faster. You can check the current recommended version here:
+
+[![latest webpack version](https://img.shields.io/github/package-json/v/webpack/webpack.svg?label=webpack&style=flat-square&maxAge=3600)](https://github.com/webpack/webpack/releases)
+
+Keeping **Node.js** current helps as well, and so does upgrading your package manager (such as `npm` or `yarn`). Recent versions produce more efficient module trees and resolve dependencies faster.
+
+### Loaders
+
+Apply loaders to as few modules as possible. Rather than this:
+
+```js
+export default {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.js$/,
+        loader: 'babel-loader',
+      },
+    ],
+  },
+};
+```
+
+Use the `include` field so the loader only runs on the modules that actually need transforming:
+
+```js
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  // ...
+  module: {
+    rules: [
+      {
+        test: /\.js$/,
+        include: path.resolve(__dirname, 'src'),
+        loader: 'babel-loader',
+      },
+    ],
+  },
+};
+```
+
+### Bootstrap
+
+Every loader and plugin adds to startup time. Keep the number of tools you rely on to a minimum.
+
+### Resolving
+
+You can speed up module resolution with the following changes:
+
+- Keep `resolve.modules`, `resolve.extensions`, `resolve.mainFiles`, and `resolve.descriptionFiles` as short as possible, since each entry adds filesystem lookups.
+- Set `resolve.symlinks: false` if you don't use symlinks (for example, `npm link` or `yarn link`).
+- Set `resolve.cacheWithContext: false` if you use custom resolving plugins that aren't context specific.
+
+### DLLs
+
+Use the `DllPlugin` to move infrequently changed code into a separate compilation. This speeds up your application's compilation at the cost of added complexity in the build process.
+
+### Smaller is faster
+
+Reducing the total size of the compilation improves build performance. Try to keep chunks small:
+
+- Use fewer and smaller libraries.
+- Use the `SplitChunksPlugin` in multi-page applications.
+- Use the `SplitChunksPlugin` in `async` mode in multi-page applications.
+- Remove unused code.
+- Only compile the part of the codebase you're currently working on.
+
+### Worker pool
+
+The `thread-loader` lets you offload expensive loaders to a pool of workers.
+
+> [!WARNING]
+> Don't spawn too many workers, since the Node.js runtime and the loader both have boot overhead. Keep module transfers between the workers and the main process to a minimum, because inter-process communication is expensive.
+
+### Persistent cache
+
+Enable the [`cache`](#TODO[/configuration/cache]) option in your webpack configuration. Clear the cache directory on `"postinstall"` in `package.json`.
+
+> [!TIP]
+> Persistent caching supports Yarn PnP version 3 ([Yarn 2 Berry](https://yarnpkg.com/features/pnp)).
+
+### Custom plugins and loaders
+
+Profile your own plugins and loaders so they don't become a performance bottleneck.
+
+### Progress plugin
+
+You can shave time off builds by removing `ProgressPlugin` from your configuration. Bear in mind that `ProgressPlugin` offers less value for already-fast builds, so weigh its benefits against the cost.
+
+## Development
+
+These steps are especially helpful during _development_.
+
+### Incremental builds
+
+Use webpack's watch mode. Avoid third-party tools that watch your files and reinvoke webpack; the built-in watch mode tracks timestamps and forwards that information to the compilation for cache invalidation.
+
+In some setups, watching falls back to polling, which can drive up CPU usage when many files are watched. In those cases, raise the polling interval with `watchOptions.poll`.
+
+### Compile in memory
+
+These utilities improve performance by compiling and serving assets from memory instead of writing them to disk:
+
+- `webpack-dev-server`
+- `webpack-hot-middleware`
+- `webpack-dev-middleware`
+
+### stats.toJson speed
+
+By default, webpack 4 emits a large amount of data through `stats.toJson()`. Avoid reading parts of the `stats` object unless you need them in the incremental step. Starting with v3.1.3, `webpack-dev-server` included a significant fix that minimizes how much data it pulls from the `stats` object on each incremental build.
+
+### Devtool
+
+Be aware of the performance trade-offs between the different `devtool` settings:
+
+- `"eval"` offers the best performance, but doesn't help with transpiled code.
+- The `cheap-source-map` variants are faster if you can accept slightly lower-quality mappings.
+- Use an `eval-source-map` variant for incremental builds.
+
+> [!TIP]
+> In most cases, `eval-cheap-module-source-map` is the best option.
+
+### Avoid production-specific tooling
+
+Certain utilities, plugins, and loaders only make sense when building for production. For instance, minifying and mangling your code with the `MinimizerPlugin` usually isn't worthwhile during development. The following tools are typically best left out in development:
+
+- `MinimizerPlugin`
+- `[fullhash]`, `[chunkhash]`, and `[contenthash]`
+- `AggressiveSplittingPlugin`
+- `AggressiveMergingPlugin`
+- `ModuleConcatenationPlugin`
+
+### Minimal entry chunk
+
+webpack only writes updated chunks to the filesystem. For some configuration options — HMR; `[name]`, `[chunkhash]`, or `[contenthash]` in `output.chunkFilename`; and `[fullhash]` — the entry chunk is invalidated alongside the changed chunks.
+
+Keep the entry chunk small so it's cheap to emit. The configuration below extracts the runtime code into its own chunk, making the entry chunk inexpensive to regenerate:
+
+```js
+export default {
+  // ...
+  optimization: {
+    runtimeChunk: true,
+  },
+};
+```
+
+### Avoid extra optimization steps
+
+webpack performs additional algorithmic work to optimize output for size and load performance. These optimizations are worthwhile for smaller codebases, but they can be costly in larger ones:
+
+```js
+export default {
+  // ...
+  optimization: {
+    removeAvailableModules: false,
+    removeEmptyChunks: false,
+    splitChunks: false,
+  },
+};
+```
+
+### Output without path info
+
+webpack can include path information in the output bundle, but this adds garbage collection pressure for projects that bundle thousands of modules. Disable it via `output.pathinfo`:
+
+```js
+export default {
+  // ...
+  output: {
+    pathinfo: false,
+  },
+};
+```
+
+### Node.js versions 8.9.10 - 9.11.1
+
+There was a [performance regression](https://github.com/nodejs/node/issues/19769) in Node.js versions 8.9.10 through 9.11.1 affecting the ES2015 `Map` and `Set` implementations. webpack uses these data structures heavily, so the regression slows down compile times. Earlier and later Node.js versions are unaffected.
+
+### TypeScript loader
+
+To improve build times with `ts-loader`, enable its `transpileOnly` option. This disables type checking on its own, so restore type checking with the [`ForkTsCheckerWebpackPlugin`](https://www.npmjs.com/package/fork-ts-checker-webpack-plugin), which moves TypeScript type checking and ESLint linting into a separate process.
+
+```js
+export default {
+  // ...
+  test: /\.tsx?$/,
+  use: [
+    {
+      loader: 'ts-loader',
+      options: {
+        transpileOnly: true,
+      },
+    },
+  ],
+};
+```
+
+> [!TIP]
+> There's a [full example](https://github.com/TypeStrong/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin) in the `ts-loader` GitHub repository.
+
+## Production
+
+These steps are especially helpful for _production_ builds.
+
+> [!WARNING]
+> Don't sacrifice the quality of your application for small performance gains. In most cases, the quality of your optimizations matters more than how fast the build runs.
+
+### Source maps
+
+Source maps are genuinely expensive to generate. Make sure you actually need them.
+
+## Specific tooling issues
+
+The tools below have known issues that can hurt build performance.
+
+### Babel
+
+- Keep the number of presets and plugins to a minimum.
+
+### TypeScript
+
+- Use `fork-ts-checker-webpack-plugin` to run type checking in a separate process.
+- Configure loaders to skip type checking.
+- Run `ts-loader` with `happyPackMode: true` and `transpileOnly: true`.
+
+### Sass
+
+- `node-sass` has a bug that blocks threads in the Node.js thread pool. When pairing it with `thread-loader`, set `workerParallelJobs: 2`.
diff --git a/pages/guides/optimization/caching.md b/pages/guides/optimization/caching.md
new file mode 100644
index 00000000..28133f99
--- /dev/null
+++ b/pages/guides/optimization/caching.md
@@ -0,0 +1,328 @@
+---
+authors: okonet,jouni-kantola,skipjack,dannycjones,fadysamirsadek,afontcu,rosavage,saiprasad2595,EugeneHlushko,AnayaDesign,aholzner,snitin315,avivkeller
+---
+
+# Caching
+
+> [!TIP]
+> The examples in this guide build on [getting started](#TODO[/guides/getting-started]), [output management](#TODO[/guides/output-management]), and [code splitting](#TODO[/guides/code-splitting]).
+
+We use webpack to bundle a modular application into a deployable `/dist` directory. Once that directory is deployed to a server, clients (usually browsers) request the site and its assets from that server. Downloading those assets can be slow, so browsers rely on a technique called [caching](<https://en.wikipedia.org/wiki/Cache_(computing)>) to load sites faster and avoid unnecessary network traffic. The downside is that caching can get in the way when you actually want clients to pick up new code.
+
+This guide covers the configuration you need so that files produced by a webpack compilation stay cached until their content actually changes.
+
+## Output filenames
+
+The `output.filename` [substitutions](#TODO[/configuration/output/#outputfilename]) setting lets us define the names of our output files. webpack supports templating filenames with bracketed strings called **substitutions**. The `[contenthash]` substitution adds a unique hash derived from an asset's content, so whenever that content changes the hash changes too.
+
+Let's set up the project using the example from [getting started](#TODO[/guides/getting-started]), along with the `plugins` from [output management](#TODO[/guides/output-management]), so we don't have to maintain `index.html` by hand:
+
+```diff displayName="project"
+webpack-demo
+ ├── package.json
+ ├── package-lock.json
+ ├── webpack.config.js
+ ├── /dist
+ ├── /src
+ │   └── index.js
+ └── /node_modules
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   plugins: [
+     new HtmlWebpackPlugin({
+-      title: 'Output Management',
++      title: 'Caching',
+     }),
+   ],
+   output: {
+-    filename: 'bundle.js',
++    filename: '[name].[contenthash].js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
+ };
+```
+
+Running the build script, `npm run build`, with this configuration should produce output like the following:
+
+```bash
+...
+                       Asset       Size  Chunks                    Chunk Names
+main.7e2c49a622975ebd9b7e.js     544 kB       0  [emitted]  [big]  main
+                  index.html  197 bytes          [emitted]
+...
+```
+
+The bundle's name now reflects its content through the hash. If we run another build without changing anything, we'd expect the filename to stay the same. However, run it again and you may find that it doesn't:
+
+```bash
+...
+                       Asset       Size  Chunks                    Chunk Names
+main.205199ab45963f6a62ec.js     544 kB       0  [emitted]  [big]  main
+                  index.html  197 bytes          [emitted]
+...
+```
+
+This happens because webpack includes certain boilerplate, specifically the runtime and manifest, in the entry chunk.
+
+> [!WARNING]
+> Your output may differ depending on the webpack version you're using. Newer versions may not have all the same hashing issues as some older versions, but we still recommend the following steps to be safe.
+
+## Extracting boilerplate
+
+As we saw in [code splitting](#TODO[/guides/code-splitting]), the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) can split modules out into separate bundles. webpack also offers an optimization that splits the runtime code into its own chunk via the [`optimization.runtimeChunk`](#TODO[/configuration/optimization/#optimizationruntimechunk]) option. Set it to `single` to create a single runtime bundle shared across all chunks:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Caching',
+     }),
+   ],
+   output: {
+     filename: '[name].[contenthash].js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
++  optimization: {
++    runtimeChunk: 'single',
++  },
+ };
+```
+
+Run another build to see the extracted `runtime` bundle:
+
+```bash
+Hash: 82c9c385607b2150fab2
+Version: webpack 4.12.0
+Time: 3027ms
+                          Asset       Size  Chunks             Chunk Names
+runtime.cc17ae2a94ec771e9221.js   1.42 KiB       0  [emitted]  runtime
+   main.e81de2cf758ada72f306.js   69.5 KiB       1  [emitted]  main
+                     index.html  275 bytes          [emitted]
+[1] (webpack)/buildin/module.js 497 bytes {1} [built]
+[2] (webpack)/buildin/global.js 489 bytes {1} [built]
+[3] ./src/index.js 309 bytes {1} [built]
+    + 1 hidden module
+```
+
+It's also good practice to extract third-party libraries, such as `lodash` or `react`, into a separate `vendor` chunk, since they change less often than our own source code. Doing so means clients have to re-download less in order to stay up to date. We can achieve this with the [`cacheGroups`](#TODO[/plugins/split-chunks-plugin/#splitchunkscachegroups]) option of the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]), as shown in [Example 2 of SplitChunksPlugin](#TODO[/plugins/split-chunks-plugin/#split-chunks-example-2]). Let's add `optimization.splitChunks` with `cacheGroups` and the following parameters, then build:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Caching',
+     }),
+   ],
+   output: {
+     filename: '[name].[contenthash].js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
+   optimization: {
+     runtimeChunk: 'single',
++    splitChunks: {
++      cacheGroups: {
++        vendor: {
++          test: /[\\/]node_modules[\\/]/,
++          name: 'vendors',
++          chunks: 'all',
++        },
++      },
++    },
+   },
+ };
+```
+
+Run another build to see the new `vendor` bundle:
+
+```bash
+...
+                          Asset       Size  Chunks             Chunk Names
+runtime.cc17ae2a94ec771e9221.js   1.42 KiB       0  [emitted]  runtime
+vendors.a42c3ca0d742766d7a28.js   69.4 KiB       1  [emitted]  vendors
+   main.abf44fedb7d11d4312d7.js  240 bytes       2  [emitted]  main
+                     index.html  353 bytes          [emitted]
+...
+```
+
+The `main` bundle no longer contains the `vendor` code from `node_modules`, and its size has dropped to just `240 bytes`.
+
+## Module identifiers
+
+Let's add another module, `print.js`, to the project:
+
+```diff displayName="project"
+webpack-demo
+ ├── package.json
+ ├── package-lock.json
+ ├── webpack.config.js
+ ├── /dist
+ ├── /src
+ │   ├── index.js
++│   └── print.js
+ └── /node_modules
+```
+
+```diff displayName="print.js"
++ export default function print(text) {
++   console.log(text);
++ };
+```
+
+```diff displayName="src/index.js"
+  import _ from 'lodash';
++ import Print from './print';
+
+  function component() {
+    const element = document.createElement('div');
+
+    // Lodash, now imported by this script
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++   element.onclick = Print.bind(null, 'Hello webpack!');
+
+    return element;
+  }
+
+  document.body.appendChild(component());
+```
+
+After running another build, we'd expect only the `main` bundle's hash to change. However:
+
+```bash
+...
+                           Asset       Size  Chunks                    Chunk Names
+  runtime.1400d5af64fc1b7b3a45.js    5.85 kB      0  [emitted]         runtime
+  vendor.a7561fb0e9a071baadb9.js     541 kB       1  [emitted]  [big]  vendor
+    main.b746e3eb72875af2caa9.js    1.22 kB       2  [emitted]         main
+                      index.html  352 bytes          [emitted]
+...
+```
+
+All three hashes changed. This is because, by default, each [`module.id`](#TODO[/api/module-variables/#moduleid-commonjs]) is assigned incrementally based on resolution order. When that order changes, the IDs change too. To recap:
+
+- The `main` bundle changed because of its new content.
+- The `vendor` bundle changed because its `module.id` changed.
+- The `runtime` bundle changed because it now references a new module.
+
+The first and last changes are expected; it's the `vendor` hash we want to keep stable. Let's set [`optimization.moduleIds`](#TODO[/configuration/optimization/#optimizationmoduleids]) to `'deterministic'`:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+ import HtmlWebpackPlugin from 'html-webpack-plugin';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   plugins: [
+     new HtmlWebpackPlugin({
+       title: 'Caching',
+     }),
+   ],
+   output: {
+     filename: '[name].[contenthash].js',
+     path: path.resolve(__dirname, 'dist'),
+     clean: true,
+   },
+   optimization: {
++    moduleIds: 'deterministic',
+     runtimeChunk: 'single',
+     splitChunks: {
+       cacheGroups: {
+         vendor: {
+           test: /[\\/]node_modules[\\/]/,
+           name: 'vendors',
+           chunks: 'all',
+         },
+       },
+     },
+   },
+ };
+```
+
+Now, regardless of any new local dependencies, the `vendor` hash should stay consistent between builds:
+
+```bash
+...
+                          Asset       Size  Chunks             Chunk Names
+   main.216e852f60c8829c2289.js  340 bytes       0  [emitted]  main
+vendors.55e79e5927a639d21a1b.js   69.5 KiB       1  [emitted]  vendors
+runtime.725a1a51ede5ae0cfde0.js   1.42 KiB       2  [emitted]  runtime
+                     index.html  353 bytes          [emitted]
+Entrypoint main = runtime.725a1a51ede5ae0cfde0.js vendors.55e79e5927a639d21a1b.js main.216e852f60c8829c2289.js
+...
+```
+
+To confirm, let's modify `src/index.js` to temporarily remove that extra dependency:
+
+```diff displayName="src/index.js"
+  import _ from 'lodash';
+- import Print from './print';
++ // import Print from './print';
+
+  function component() {
+    const element = document.createElement('div');
+
+    // Lodash, now imported by this script
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+-   element.onclick = Print.bind(null, 'Hello webpack!');
++   // element.onclick = Print.bind(null, 'Hello webpack!');
+
+    return element;
+  }
+
+  document.body.appendChild(component());
+```
+
+And run the build one more time:
+
+```bash
+...
+                          Asset       Size  Chunks             Chunk Names
+   main.ad717f2466ce655fff5c.js  274 bytes       0  [emitted]  main
+vendors.55e79e5927a639d21a1b.js   69.5 KiB       1  [emitted]  vendors
+runtime.725a1a51ede5ae0cfde0.js   1.42 KiB       2  [emitted]  runtime
+                     index.html  353 bytes          [emitted]
+Entrypoint main = runtime.725a1a51ede5ae0cfde0.js vendors.55e79e5927a639d21a1b.js main.ad717f2466ce655fff5c.js
+...
+```
+
+Both builds produced `55e79e5927a639d21a1b` in the `vendor` bundle's filename, exactly as we wanted.
+
+## Conclusion
+
+Caching can be tricky, but the benefit it brings to your application's or site's users makes the effort worthwhile. See the _Further reading_ section below to learn more.
+
+## Further reading
+
+- [Issue 652](https://github.com/webpack/webpack.js.org/issues/652)
diff --git a/pages/guides/optimization/code-splitting/index.md b/pages/guides/optimization/code-splitting/index.md
new file mode 100644
index 00000000..e719c921
--- /dev/null
+++ b/pages/guides/optimization/code-splitting/index.md
@@ -0,0 +1,461 @@
+---
+authors: pksjce,pastelsky,simon04,jonwheeler,johnstew,shinxi,tomtasche,levy9527,rahulcs,chrisVillanueva,rafde,bartushek,shaunwallace,skipjack,jakearchibald,TheDutchCoder,rouzbeh84,shaodahong,sudarsangp,kcolton,efreitasn,EugeneHlushko,Tiendo1011,byzyk,AnayaDesign,wizardofhogwarts,maximilianschmelzer,smelukov,chenxsan,Adarah,atesgoral,snitin315,artem-malko,Brennvo,ThierryRakotomanana,avivkeller
+---
+
+# Code Splitting
+
+> [!TIP]
+> This guide builds on the example from [Getting Started](#TODO[/guides/getting-started]). Make sure you are at least familiar with that example and the [Output Management](#TODO[/guides/output-management/]) chapter before continuing.
+
+Code splitting is one of webpack's most compelling features. It lets you split your code into multiple bundles that can be loaded on demand or in parallel. Used well, it produces smaller bundles and gives you control over resource load prioritization, which can have a significant impact on load time.
+
+There are three general approaches to code splitting:
+
+- **Entry points**: Manually split code using the [`entry`](#TODO[/configuration/entry-context]) configuration.
+- **Prevent duplication**: Use [entry dependencies](#TODO[/configuration/entry-context/#dependencies]) or the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) to deduplicate and split chunks.
+- **Dynamic imports**: Split code through inline function calls within modules.
+
+## Entry Points
+
+This is by far the easiest and most intuitive way to split code. It is, however, more manual and comes with a few pitfalls we will cover below. Let's look at how we might split another module out of the main bundle:
+
+```diff displayName="project"
+ webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
++ │   └── another-module.js
+  └── /node_modules
+```
+
+```js displayName="another-module.js"
+import _ from 'lodash';
+
+console.log(_.join(['Another', 'module', 'loaded!'], ' '));
+```
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+-  entry: './src/index.js',
++  mode: 'development',
++  entry: {
++    index: './src/index.js',
++    another: './src/another-module.js',
++  },
+   output: {
+-    filename: 'main.js',
++    filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+ };
+```
+
+This produces the following build result:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset index.bundle.js 553 KiB [emitted] (name: index)
+asset another.bundle.js 553 KiB [emitted] (name: another)
+runtime modules 2.49 KiB 12 modules
+cacheable modules 530 KiB
+  ./src/index.js 257 bytes [built] [code generated]
+  ./src/another-module.js 84 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 245 ms
+```
+
+As mentioned, this approach has a few pitfalls:
+
+- Any modules duplicated between entry chunks will be included in both bundles.
+- It isn't flexible and can't be used to dynamically split code together with the core application logic.
+
+The first point is clearly a problem in our example: `lodash` is also imported in `./src/index.js`, so it ends up duplicated in both bundles. Let's remove that duplication in the next section.
+
+## Prevent Duplication
+
+### Entry dependencies
+
+The [`dependOn` option](#TODO[/configuration/entry-context/#dependencies]) lets you share modules between chunks:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+-    index: './src/index.js',
+-    another: './src/another-module.js',
++    index: {
++      import: './src/index.js',
++      dependOn: 'shared',
++    },
++    another: {
++      import: './src/another-module.js',
++      dependOn: 'shared',
++    },
++    shared: 'lodash',
+   },
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+ };
+```
+
+If you plan to use multiple entry points on a single HTML page, you also need `optimization.runtimeChunk: 'single'`. Without it, you can run into the problem described [here](https://bundlers.tooling.report/code-splitting/multi-entry/).
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+     index: {
+       import: './src/index.js',
+       dependOn: 'shared',
+     },
+     another: {
+       import: './src/another-module.js',
+       dependOn: 'shared',
+     },
+     shared: 'lodash',
+   },
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
++  optimization: {
++    runtimeChunk: 'single',
++  },
+ };
+```
+
+This yields the following build result:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset shared.bundle.js 549 KiB [compared for emit] (name: shared)
+asset runtime.bundle.js 7.79 KiB [compared for emit] (name: runtime)
+asset index.bundle.js 1.77 KiB [compared for emit] (name: index)
+asset another.bundle.js 1.65 KiB [compared for emit] (name: another)
+Entrypoint index 1.77 KiB = index.bundle.js
+Entrypoint another 1.65 KiB = another.bundle.js
+Entrypoint shared 557 KiB = runtime.bundle.js 7.79 KiB shared.bundle.js 549 KiB
+runtime modules 3.76 KiB 7 modules
+cacheable modules 530 KiB
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+  ./src/another-module.js 84 bytes [built] [code generated]
+  ./src/index.js 257 bytes [built] [code generated]
+webpack 5.x.x compiled successfully in 249 ms
+```
+
+As you can see, alongside `shared.bundle.js`, `index.bundle.js`, and `another.bundle.js`, there's now an additional `runtime.bundle.js` file.
+
+Although webpack allows multiple entry points per page, you should avoid it when possible in favor of a single entry point with multiple imports, such as `entry: { page: ['./analytics', './app'] }`. This results in better optimization and a consistent execution order when using `async` script tags.
+
+### SplitChunksPlugin
+
+The [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) lets you extract common dependencies into an existing entry chunk or an entirely new one. Let's use it to deduplicate the `lodash` dependency from the previous example:
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    mode: 'development',
+    entry: {
+      index: './src/index.js',
+      another: './src/another-module.js',
+    },
+    output: {
+      filename: '[name].bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+    },
++   optimization: {
++     splitChunks: {
++       chunks: 'all',
++     },
++   },
+  };
+```
+
+With the [`optimization.splitChunks`](#TODO[/plugins/split-chunks-plugin/#optimizationsplitchunks]) option in place, the duplicate dependency should now be removed from both `index.bundle.js` and `another.bundle.js`. The plugin recognizes that `lodash` has been separated into its own chunk and strips the dead weight from the main bundles. Note, however, that common dependencies are only extracted into a separate chunk if they meet the [size thresholds](#TODO[/plugins/split-chunks-plugin/#splitchunksminsize]) specified by webpack.
+
+Run `npm run build` to confirm it worked:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset vendors-node_modules_lodash_lodash_js.bundle.js 549 KiB [compared for emit] (id hint: vendors)
+asset index.bundle.js 8.92 KiB [compared for emit] (name: index)
+asset another.bundle.js 8.8 KiB [compared for emit] (name: another)
+Entrypoint index 558 KiB = vendors-node_modules_lodash_lodash_js.bundle.js 549 KiB index.bundle.js 8.92 KiB
+Entrypoint another 558 KiB = vendors-node_modules_lodash_lodash_js.bundle.js 549 KiB another.bundle.js 8.8 KiB
+runtime modules 7.64 KiB 14 modules
+cacheable modules 530 KiB
+  ./src/index.js 257 bytes [built] [code generated]
+  ./src/another-module.js 84 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 241 ms
+```
+
+Here are some other useful community plugins and loaders for splitting code:
+
+- [`mini-css-extract-plugin`](#TODO[/plugins/mini-css-extract-plugin]): Useful for splitting CSS out of the main application.
+
+## Dynamic Imports
+
+webpack supports two similar techniques for dynamic code splitting. The first and recommended approach is the [`import()` syntax](#TODO[/api/module-methods/#import-1]), which conforms to the [ECMAScript proposal](https://github.com/tc39/proposal-dynamic-import) for dynamic imports. The legacy, webpack-specific approach uses [`require.ensure`](#TODO[/api/module-methods/#requireensure]). Let's try the first of these.
+
+> [!WARNING]
+> `import()` calls use [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) internally. If you use `import()` with older browsers (such as IE 11), remember to shim `Promise` with a polyfill like [es6-promise](https://github.com/stefanpenner/es6-promise) or [promise-polyfill](https://github.com/taylorhakes/promise-polyfill).
+
+Before we begin, let's remove the extra [`entry`](#TODO[/concepts/entry-points/]) and [`optimization.splitChunks`](#TODO[/plugins/split-chunks-plugin]) configuration from the previous example, since they aren't needed for this demonstration:
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   mode: 'development',
+   entry: {
+     index: './src/index.js',
+-    another: './src/another-module.js',
+   },
+   output: {
+     filename: '[name].bundle.js',
+     path: path.resolve(__dirname, 'dist'),
+   },
+-  optimization: {
+-    splitChunks: {
+-      chunks: 'all',
+-    },
+-  },
+ };
+```
+
+We'll also update the project to remove the now unused file:
+
+```diff displayName="project"
+ webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
+- │   └── another-module.js
+  └── /node_modules
+```
+
+Now, instead of statically importing `lodash`, we'll use a dynamic import to split it into its own chunk:
+
+```diff displayName="src/index.js"
+-import _ from 'lodash';
+-
+-function component() {
++function getComponent() {
+-  const element = document.createElement('div');
+
+-  // Lodash, now imported by this script
+-  element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++  return import('lodash')
++    .then(({ default: _ }) => {
++      const element = document.createElement('div');
++
++      element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+-  return element;
++      return element;
++    })
++    .catch((error) => 'An error occurred while loading the component');
+ }
+
+-document.body.appendChild(component());
++getComponent().then((component) => {
++  document.body.appendChild(component);
++});
+```
+
+We need `default` here because, since webpack 4, importing a CommonJS module no longer resolves to the value of `module.exports`. Instead, webpack creates an artificial namespace object for the CommonJS module. For more background, read [webpack 4: import() and CommonJs](https://medium.com/webpack/webpack-4-import-and-commonjs-d619d626b655).
+
+Run webpack to see `lodash` split out into a separate bundle:
+
+```bash
+...
+[webpack-cli] Compilation finished
+asset vendors-node_modules_lodash_lodash_js.bundle.js 549 KiB [compared for emit] (id hint: vendors)
+asset index.bundle.js 13.5 KiB [compared for emit] (name: index)
+runtime modules 7.37 KiB 11 modules
+cacheable modules 530 KiB
+  ./src/index.js 434 bytes [built] [code generated]
+  ./node_modules/lodash/lodash.js 530 KiB [built] [code generated]
+webpack 5.x.x compiled successfully in 268 ms
+```
+
+> [!TIP]
+> You can also use the `webpackExports` magic comment with `import()` to expose specific exports from a dynamically imported module:
+>
+> ```js
+> import(
+>   /* webpackExports: ["default", "namedExport"] */
+>   './module'
+> );
+> ```
+>
+> This helps webpack tree shake the other unused exports. See [Magic Comments](#TODO[/api/module-methods/#magic-comments]) for details.
+
+Because `import()` returns a promise, it can be used with [`async` functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function). Here's how that simplifies the code:
+
+```diff displayName="src/index.js"
+-function getComponent() {
++async function getComponent() {
++  const element = document.createElement('div');
++  const { default: _ } = await import('lodash');
+
+-  return import('lodash')
+-    .then(({ default: _ }) => {
+-      const element = document.createElement('div');
++  element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+-      element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+-
+-      return element;
+-    })
+-    .catch((error) => 'An error occurred while loading the component');
++  return element;
+ }
+
+ getComponent().then((component) => {
+   document.body.appendChild(component);
+ });
+```
+
+> [!TIP]
+> You can also provide a [dynamic expression](#TODO[/api/module-methods/#dynamic-expressions-in-import]) to `import()` when you need to import a specific module based on a value computed later.
+
+### Understanding ChunkLoadError
+
+When using dynamic `import()` or code splitting, webpack may throw a `ChunkLoadError` if a chunk fails to load at runtime.
+
+This error usually means the requested chunk could not be executed or resolved properly. In some cases, the browser's underlying network or script-loading error isn't fully reflected in the `ChunkLoadError` message itself.
+
+If you encounter this error:
+
+- Verify that the chunk file is accessible over the network.
+- Check that the `publicPath` is configured correctly.
+- Inspect the browser console for additional script or network errors.
+
+For more context, see the related discussion in the webpack issue tracker.
+
+## Prefetching/Preloading modules
+
+webpack 4.6.0+ adds support for prefetching and preloading.
+
+Using these inline directives when declaring your imports lets webpack output a "Resource Hint" that tells the browser:
+
+- **prefetch**: the resource is probably needed for some navigation in the future.
+- **preload**: the resource will also be needed during the current navigation.
+
+For example, consider a `HomePage` component that renders a `LoginButton` component, which in turn loads a `LoginModal` component on demand after being clicked.
+
+```js displayName="LoginButton.js"
+// ...
+import(/* webpackPrefetch: true */ './path/to/LoginModal.js');
+```
+
+This appends `<link rel="prefetch" href="login-modal-chunk.js">` to the page's head, instructing the browser to prefetch the `login-modal-chunk.js` file during idle time.
+
+> [!TIP]
+> webpack adds the prefetch hint once the parent chunk has finished loading.
+
+Preload differs from prefetch in several ways:
+
+- A preloaded chunk starts loading in parallel with the parent chunk, whereas a prefetched chunk starts after the parent chunk finishes loading.
+- A preloaded chunk has medium priority and is downloaded immediately, whereas a prefetched chunk is downloaded while the browser is idle.
+- A preloaded chunk should be requested immediately by the parent chunk, whereas a prefetched chunk can be used at any point in the future.
+- Browser support differs.
+
+As an example, consider a `Component` that always depends on a large library, which should live in a separate chunk.
+
+Imagine a `ChartComponent` that needs a huge `ChartingLibrary`. It displays a `LoadingIndicator` when rendered and immediately performs an on-demand import of `ChartingLibrary`:
+
+```js displayName="ChartComponent.js"
+// ...
+import(/* webpackPreload: true */ 'ChartingLibrary');
+```
+
+When a page that uses `ChartComponent` is requested, the charting-library-chunk is also requested via `<link rel="preload">`. Assuming the page-chunk is smaller and finishes first, the page renders with a `LoadingIndicator` until the already-requested charting-library-chunk finishes. This gives a small load-time boost, since it requires only one round trip instead of two, especially in high-latency environments.
+
+> [!TIP]
+> Using `webpackPreload` incorrectly can actually hurt performance, so use it with care.
+
+Sometimes you need direct control over preloading. For example, you can preload any dynamic import via an async script, which is useful for streaming server-side rendering.
+
+```js
+const lazyComp = () =>
+  import('DynamicComponent').catch(error => {
+    // Do something with the error.
+    // For example, we can retry the request in case of a network error.
+  });
+```
+
+If the script fails to load before webpack starts loading it on its own (webpack creates a script tag to load its code if that script isn't already on the page), the `catch` handler won't run until [chunkLoadTimeout](#TODO[/configuration/output/#outputchunkloadtimeout]) is reached. This behavior can be surprising, but it's explainable: webpack can't throw an error because it doesn't know the script failed. webpack adds an `onerror` handler to the script only after the error has already happened.
+
+To avoid this problem, add your own `onerror` handler that removes the script whenever an error occurs:
+
+```html
+<script
+  src="https://example.com/dist/dynamicComponent.js"
+  async
+  onerror="this.remove()"
+></script>
+```
+
+In that case, the errored script is removed. webpack then creates its own script, and any error is processed without timeouts.
+
+## Bundle Analysis
+
+Once you start splitting your code, it can be helpful to analyze the output to see where modules ended up. The [official analyze tool](https://github.com/webpack/analyse) is a good place to start. There are also several community-supported options:
+
+- [webpack-chart](https://alexkuz.github.io/webpack-chart/): Interactive pie chart for webpack stats.
+- [webpack-visualizer](https://chrisbateman.github.io/webpack-visualizer/): Visualize and analyze your bundles to see which modules take up space and which might be duplicates.
+- [webpack-bundle-analyzer](https://github.com/webpack/webpack-bundle-analyzer): A plugin and CLI utility that represents bundle content as a convenient, interactive, zoomable treemap.
+- [webpack bundle optimize helper](https://webpack.jakoblind.no/optimize): Analyzes your bundle and gives you actionable suggestions for reducing its size.
+- [bundle-stats](https://github.com/bundle-stats/bundle-stats): Generates a bundle report (bundle size, assets, modules) and compares the results between different builds.
+- [webpack-stats-viewer](https://github.com/moonrailgun/webpack-stats-viewer): A plugin with a build for webpack stats that shows more detail about your webpack bundle.
+
+## Next Steps
+
+See [Lazy Loading](#TODO[/guides/lazy-loading/]) for a more concrete example of how `import()` can be used in a real application, and [Caching](#TODO[/guides/caching/]) to learn how to split code more effectively.
+
+## Further reading
+
+- [`<link rel="prefetch/preload" />` in webpack](https://medium.com/webpack/link-rel-prefetch-preload-in-webpack-51a52358f84c)
+- [Preload, Prefetch And Priorities in Chrome](https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf)
+- [Preloading content with `<link rel="preload" />`](https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content)
diff --git a/pages/guides/optimization/code-splitting/lazy-loading.md b/pages/guides/optimization/code-splitting/lazy-loading.md
new file mode 100644
index 00000000..44b9a7f5
--- /dev/null
+++ b/pages/guides/optimization/code-splitting/lazy-loading.md
@@ -0,0 +1,237 @@
+---
+authors: iammerrick,chrisVillanueva,skipjack,byzyk,EugeneHlushko,AnayaDesign,tapanprakasht,snitin315,ThierryRakotomanana,avivkeller
+---
+
+# Lazy Loading
+
+> [!TIP]
+> This guide is a short follow-up to [Code Splitting](#TODO[/guides/code-splitting]). If you haven't read through that guide yet, please do so now.
+
+Lazy, or "on demand", loading is a great way to optimize your site or application. The practice essentially involves splitting your code at logical breakpoints and then loading a block of code once the user does something that requires it (or will soon require it). This speeds up the initial load of the application and lightens its overall weight, since some blocks may never be loaded at all.
+
+## Dynamic import example
+
+Let's take the example from [Code Splitting](#TODO[/guides/code-splitting/#dynamic-imports]) and tweak it to demonstrate this concept more clearly. The code there does cause a separate chunk, `lodash.bundle.js`, to be generated and technically "lazy-loads" it as soon as the script runs. The trouble is that no user interaction is required to load the bundle, which means the request fires every time the page loads. That doesn't help us much and negatively impacts performance.
+
+Let's try something different. We'll add an interaction that logs some text to the console when the user clicks a button. However, we'll wait to load that code (`print.js`) until the interaction occurs for the first time. To do this, we'll go back and rework the [final _Dynamic Imports_ example](#TODO[/guides/code-splitting/#dynamic-imports]) from _Code Splitting_, leaving `lodash` in the main chunk.
+
+```diff displayName="project"
+webpack-demo
+ ├── package.json
+ ├── package-lock.json
+ ├── webpack.config.js
+ ├── /dist
+ ├── /src
+ │   ├── index.js
++│   └── print.js
+ └── /node_modules
+```
+
+```js displayName="src/print.js"
+console.log(
+  'The print.js module has loaded! See the network tab in dev tools...'
+);
+
+export default () => {
+  console.log('Button Clicked: Here\'s "some text"!');
+};
+```
+
+```diff displayName="src/index.js"
++ import _ from 'lodash';
++
+- async function getComponent() {
++ function component() {
+    const element = document.createElement('div');
+-   const _ = await import(/* webpackChunkName: "lodash" */ 'lodash');
++   const button = document.createElement('button');
++   const br = document.createElement('br');
+
++   button.innerHTML = 'Click me and look at the console!';
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++   element.appendChild(br);
++   element.appendChild(button);
++
++   // Note that because a network request is involved, some indication
++   // of loading would need to be shown in a production-level site/app.
++   button.onclick = e => import(/* webpackChunkName: "print" */ './print').then(module => {
++     const print = module.default;
++
++     print();
++   });
+
+    return element;
+  }
+
+- getComponent().then(component => {
+-   document.body.appendChild(component);
+- });
++ document.body.appendChild(component());
+```
+
+> [!WARNING]
+> Note that when using `import()` on ES6 modules, you must reference the `.default` property, as it is the actual `module` object returned when the promise resolves.
+
+Now let's run webpack and check out our new lazy-loading functionality:
+
+```bash
+...
+          Asset       Size  Chunks                    Chunk Names
+print.bundle.js  417 bytes       0  [emitted]         print
+index.bundle.js     548 kB       1  [emitted]  [big]  index
+     index.html  189 bytes          [emitted]
+...
+```
+
+## Defer import example
+
+> [!WARNING]
+> This feature does not lazily "load" a module; it lazily "evaluates" one. The module is still downloaded and parsed, but its evaluation is deferred.
+
+In some cases, it can be annoying or difficult to convert all uses of a module to asynchronous code, since doing so forces the unnecessary asyncification of all functions without providing a way to defer only the synchronous evaluation work.
+
+The TC39 proposal [Deferring Module Evaluation](https://github.com/tc39/proposal-defer-import-eval) aims to solve this problem.
+
+> The proposal is to have a new syntactical import form which will only ever return a namespace exotic object. When used, the module and its dependencies would not be executed, but would be fully loaded to the point of being execution-ready before the module graph is considered loaded.
+>
+> _Only when accessing a property of this module, would the execution operations be performed (if needed)._
+
+This feature is available by enabling [experiments.deferImport](#TODO[/configuration/experiments/#experimentsdeferimport]).
+
+> [!WARNING]
+> This feature is still in the experimental stage and may change in future versions of webpack.
+
+```diff displayName="project"
+ webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  ├── /src
+  │   ├── index.js
++ │   └── print.js
+  └── /node_modules
+```
+
+```js displayName="src/print.js"
+console.log(
+  'The print.js module has loaded! See the network tab in dev tools...'
+);
+
+export default () => {
+  console.log('Button Clicked: Here\'s "some text"!');
+};
+```
+
+```diff displayName="src/index.js"
+  import _ from 'lodash';
++ import defer * as print from './print';
+
+  function component() {
+    const element = document.createElement('div');
+    const button = document.createElement('button');
+    const br = document.createElement('br');
+
+    button.innerHTML = 'Click me and look at the console!';
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+    element.appendChild(br);
+    element.appendChild(button);
+
+-   // Note that because a network request is involved, some indication
+-   // of loading would need to be shown in a production-level site/app.
++   // In this example, the print module is downloaded but not evaluated,
++   // so there is no network request involved after the button is clicked.
+-   button.onclick = e => import(/* webpackChunkName: "print" */ './print').then(module => {
++   button.onclick = e => {
+      const print = module.default;
++     //                  ^ The module is evaluated here.
+
+      print();
+-   });
++   };
+
+    return element;
+  }
+
+  getComponent().then(component => {
+    document.body.appendChild(component);
+  });
+  document.body.appendChild(component());
+```
+
+This is similar to the CommonJS style of lazy loading:
+
+```diff displayName="src/index.js"
+  import _ from 'lodash';
+- import defer * as print from './print';
+
+  function component() {
+    const element = document.createElement('div');
+    const button = document.createElement('button');
+    const br = document.createElement('br');
+
+    button.innerHTML = 'Click me and look at the console!';
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+    element.appendChild(br);
+    element.appendChild(button);
+
+    // In this example, the print module is downloaded but not evaluated,
+    // so there is no network request involved after the button is clicked.
+    button.onclick = e => {
++     const print = require('./print');
++     //            ^ The module is evaluated here.
+      const print = module.default;
+-     //                  ^ The module is evaluated here.
+
+      print();
+    };
+
+    return element;
+  }
+
+  getComponent().then(component => {
+    document.body.appendChild(component);
+  });
+  document.body.appendChild(component());
+```
+
+### Using `import.defer()` with context modules
+
+<!-- TODO: Badge text="5.105.0+" -->
+
+`import.defer()` also works with context modules: the import path can be a dynamic expression. webpack includes all matching modules in the module graph, but evaluation of the selected module is deferred until a property on the namespace object is first accessed.
+
+The following example demonstrates deferred evaluation of locale modules using a dynamic context path:
+
+```js displayName="src/locales/en.js"
+export const greeting = 'Hello';
+```
+
+```js displayName="src/locales/fr.js"
+export const greeting = 'Bonjour';
+```
+
+```text displayName="src/index.js"
+const language = navigator.language.split("-")[0]; // "en", "fr", etc.
+const locale = import.defer("./locales/" + language + ".js");
+
+document.getElementById("btn").addEventListener("click", () => {
+  // The locale module is evaluated here, on first property access.
+  document.getElementById("output").textContent = locale.greeting;
+});
+```
+
+webpack prepares all matching locale modules so they are ready for execution, but the selected module is only evaluated when `locale.greeting` is first accessed. This lets you load multiple locale files without executing them immediately.
+
+## Frameworks
+
+Many frameworks and libraries have their own recommendations for accomplishing this within their methodologies. Here are a few examples:
+
+- React: [Code Splitting and Lazy Loading](https://react.dev/learn/build-a-react-app-from-scratch#code-splitting)
+- Vue: [Dynamic Imports in Vue.js for better performance](https://vuedose.tips/tips/dynamic-imports-in-vue-js-for-better-performance/)
+- Angular: [Lazy Loading route configuration](https://angular.io/guide/router#milestone-6-asynchronous-routing) and [AngularJS + webpack = lazyLoad](https://medium.com/@var_bin/angularjs-webpack-lazyload-bb7977f390dd)
+
+## Further reading
+
+- [Lazy Loading ES2015 Modules in the Browser](https://dzone.com/articles/lazy-loading-es2015-modules-in-the-browser)
+- [Asynchronous vs Deferred JavaScript](https://bitsofco.de/async-vs-defer/)
diff --git a/pages/guides/optimization/tree-shaking.md b/pages/guides/optimization/tree-shaking.md
new file mode 100644
index 00000000..0b206cd7
--- /dev/null
+++ b/pages/guides/optimization/tree-shaking.md
@@ -0,0 +1,576 @@
+---
+authors: simon04,zacanger,alexjoverm,avant1,MijaelWatts,dmitriid,probablyup,gish,lumo10,byzyk,pnevares,EugeneHlushko,AnayaDesign,torifat,rahul3v,snitin315,vansh5632,Brennvo,ThierryRakotomanana,avivkeller
+---
+
+# Tree Shaking
+
+_Tree shaking_ is a term commonly used in JavaScript for dead-code elimination. It relies on the [static structure](http://exploringjs.com/es6/ch_modules.html#static-module-structure) of ES2015 module syntax — that is, [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) and [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export). The name and concept were popularized by the ES2015 module bundler [rollup](https://github.com/rollup/rollup).
+
+webpack 2 introduced built-in support for ES2015 modules (also known as _harmony modules_) along with detection of unused module exports. webpack 4 expanded on this by letting you hint to the compiler, via the `"sideEffects"` property in `package.json`, which files in your project are "pure" and therefore safe to prune if unused.
+
+> [!TIP]
+> The rest of this guide builds on [Getting Started](#TODO[/guides/getting-started]). If you haven't read through that guide yet, please do so now.
+
+## Add a utility
+
+Let's add a new utility file to our project, `src/math.js`, that exports two functions:
+
+```diff displayName="project"
+ webpack-demo
+  ├── package.json
+  ├── package-lock.json
+  ├── webpack.config.js
+  ├── /dist
+  │   ├── bundle.js
+  │   └── index.html
+  ├── /src
+  │   ├── index.js
++ │   └── math.js
+  └── /node_modules
+```
+
+```js displayName="src/math.js"
+export function square(x) {
+  return x * x;
+}
+
+export function cube(x) {
+  return x * x * x;
+}
+```
+
+Set the `mode` configuration option to [development](#TODO[/configuration/mode/#mode-development]) to make sure the bundle is not minified:
+
+```diff displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'bundle.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
++ mode: 'development',
++ optimization: {
++   usedExports: true,
++ },
+};
+```
+
+With that in place, let's update our entry script to use one of these new methods and remove `lodash` for simplicity:
+
+```diff displayName="src/index.js"
+- import _ from 'lodash';
++ import { cube } from './math.js';
+
+  function component() {
+-   const element = document.createElement('div');
++   const element = document.createElement('pre');
+
+-   // Lodash, now imported by this script
+-   element.innerHTML = _.join(['Hello', 'webpack'], ' ');
++   element.innerHTML = [
++     'Hello webpack!',
++     '5 cubed is equal to ' + cube(5)
++   ].join('\n\n');
+
+    return element;
+  }
+
+  document.body.appendChild(component());
+```
+
+Note that we **did not `import` the `square` method** from the `src/math.js` module. That function is what's known as "dead code": an unused `export` that should be dropped. Now let's run our npm script, `npm run build`, and inspect the output bundle:
+
+```js displayName="dist/bundle.js (around lines 90 - 100)"
+/* 1 */
+/***/ (function (module, __webpack_exports__, __webpack_require__) {
+  'use strict';
+
+  /* unused harmony export square */
+  /* harmony export (immutable) */ __webpack_exports__.a = cube;
+  function square(x) {
+    return x * x;
+  }
+
+  function cube(x) {
+    return x * x * x;
+  }
+});
+```
+
+Note the `unused harmony export square` comment above. If you look at the code below it, you'll notice that `square` is not imported, yet it is still included in the bundle. We'll fix that in the next section.
+
+## Mark the file as side-effect-free
+
+In a 100% ESM world, identifying side effects would be straightforward. We aren't there quite yet, however, so in the meantime we need to hint to webpack's compiler about the "purity" of your code.
+
+This is done through the `"sideEffects"` property in `package.json`:
+
+```json
+{
+  "name": "your-project",
+  "sideEffects": false
+}
+```
+
+None of the code above contains side effects, so we can set the property to `false` to tell webpack it can safely prune unused exports.
+
+> [!TIP]
+> A "side effect" is code that performs special behavior when imported, beyond exposing one or more exports. Polyfills are an example: they affect the global scope and usually don't provide an export.
+
+If your code does have side effects, you can provide an array instead:
+
+```json
+{
+  "name": "your-project",
+  "sideEffects": ["./src/some-side-effectful-file.js"]
+}
+```
+
+The array accepts simple glob patterns to the relevant files. It uses [glob-to-regexp](https://github.com/fitzgen/glob-to-regexp) under the hood (it supports `*`, `**`, `{a,b}`, and `[a-z]`). Patterns like `*.css`, which don't include a `/`, are treated like `**/*.css`.
+
+> [!TIP]
+> Any imported file is subject to tree shaking. This means that if you use something like `css-loader` and import a CSS file, it must be added to the side-effects list so it isn't unintentionally dropped in production mode:
+
+```json
+{
+  "name": "your-project",
+  "sideEffects": ["./src/some-side-effectful-file.js", "*.css"]
+}
+```
+
+Finally, `"sideEffects"` can also be set from the [`module.rules` configuration option](#TODO[/configuration/module/#modulerules]).
+
+## Clarifying tree shaking and `sideEffects`
+
+The [`sideEffects`](#TODO[/configuration/optimization/#optimizationsideeffects]) and [`usedExports`](#TODO[/configuration/optimization/#optimizationusedexports]) (better known as tree shaking) optimizations are two different things.
+
+**`sideEffects` is much more effective**, because it allows webpack to skip whole modules/files and their complete subtree.
+
+`usedExports` relies on [terser](https://github.com/terser-js/terser) to detect side effects in statements. That's a difficult task in JavaScript and not as effective as the straightforward `sideEffects` flag. It also can't skip subtrees or dependencies, because the spec requires side effects to be evaluated. While exporting a function works fine, React's Higher-Order Components (HOCs) are problematic in this regard.
+
+If you're using dynamic `import()`, you can also use the `webpackExports` magic comment to specify which exports should be exposed, allowing webpack to tree shake the rest. See [Magic Comments](#TODO[/api/module-methods/#magic-comments]).
+
+Let's look at an example:
+
+```js
+import { Button } from '@shopify/polaris';
+```
+
+The pre-bundled version looks like this:
+
+```js
+import hoistStatics from 'hoist-non-react-statics';
+
+function Button(_ref) {
+  // ...
+}
+
+function merge() {
+  const _final = {};
+
+  for (
+    let _len = arguments.length, objs = Array.from({ length: _len }), _key = 0;
+    _key < _len;
+    _key++
+  ) {
+    objs[_key] = arguments[_key];
+  }
+
+  for (let _i = 0, _objs = objs; _i < _objs.length; _i++) {
+    const obj = _objs[_i];
+    mergeRecursively(_final, obj);
+  }
+
+  return _final;
+}
+
+function withAppProvider() {
+  return function addProvider(WrappedComponent) {
+    const WithProvider =
+      /*#__PURE__*/
+      (function (_React$Component) {
+        // ...
+        return WithProvider;
+      })(Component);
+
+    WithProvider.contextTypes = WrappedComponent.contextTypes
+      ? merge(WrappedComponent.contextTypes, polarisAppProviderContextTypes)
+      : polarisAppProviderContextTypes;
+    const FinalComponent = hoistStatics(WithProvider, WrappedComponent);
+    return FinalComponent;
+  };
+}
+
+const Button$1 = withAppProvider()(Button);
+
+export {
+  // ...,
+  Button$1,
+};
+```
+
+When `Button` is unused, you can effectively remove `export { Button$1 };`, which leaves all the remaining code intact. So the question becomes: "Does this code have any side effects, or can it be safely removed?" That's difficult to answer, especially because of this line: `withAppProvider()(Button)`. `withAppProvider` is called and its return value is also called. Are there side effects when calling `merge` or `hoistStatics`? Are there side effects when assigning `WithProvider.contextTypes` (a setter?) or reading `WrappedComponent.contextTypes` (a getter?).
+
+terser does try to figure this out, but in many cases it can't be sure. This doesn't mean terser isn't doing its job well; it's simply too difficult to determine reliably in a dynamic language like JavaScript.
+
+But we can help terser with the `/*#__PURE__*/` annotation. It flags a statement as side-effect-free. So a small change makes it possible to tree shake the code:
+
+```js
+const Button$1 = /* #__PURE__ */ withAppProvider()(Button);
+```
+
+This allows the piece of code to be removed. But there are still questions about the imports, which need to be included and evaluated because they could contain side effects.
+
+To tackle this, we use the [`"sideEffects"`](#TODO[/guides/tree-shaking/#mark-the-file-as-side-effect-free]) property in `package.json`.
+
+It's similar to `/*#__PURE__*/`, but at the module level rather than the statement level. The `"sideEffects"` property says: "If no direct export from a module flagged as side-effect-free is used, the bundler can skip evaluating the module for side effects."
+
+In Shopify's Polaris example, the original modules look like this:
+
+```js displayName="index.js"
+import './configure';
+
+export * from './types';
+export * from './components';
+```
+
+```js displayName="components/index.js"
+// ...
+export { default as Breadcrumbs } from './Breadcrumbs';
+export { buttonFrom, buttonsFrom, default as Button } from './Button';
+export { default as ButtonGroup } from './ButtonGroup';
+// ...
+```
+
+```json displayName="package.json"
+// ...
+"sideEffects": [
+  "**/*.css",
+  "**/*.scss",
+  "./esnext/index.js",
+  "./esnext/configure.js"
+],
+// ...
+```
+
+For `import { Button } from "@shopify/polaris";`, this has the following implications:
+
+- include it: include the module, evaluate it, and continue analyzing dependencies
+- skip over: don't include it, don't evaluate it, but continue analyzing dependencies
+- exclude it: don't include it, don't evaluate it, and don't analyze dependencies
+
+Specifically, per matching resource:
+
+- `index.js`: No direct export is used, but it's flagged with `sideEffects` -> include it.
+- `configure.js`: No export is used, but it's flagged with `sideEffects` -> include it.
+- `types/index.js`: No export is used, not flagged with `sideEffects` -> exclude it.
+- `components/index.js`: No direct export is used and it's not flagged with `sideEffects`, but re-exported exports are used -> skip over.
+- `components/Breadcrumbs.js`: No export is used, not flagged with `sideEffects` -> exclude it. This also excludes all of its dependencies, like `components/Breadcrumbs.css`, even if they are flagged with `sideEffects`.
+- `components/Button.js`: A direct export is used, not flagged with `sideEffects` -> include it.
+- `components/Button.css`: No export is used, but it's flagged with `sideEffects` -> include it.
+
+In this case, only four modules end up in the bundle:
+
+- `index.js`: pretty much empty
+- `configure.js`
+- `components/Button.js`
+- `components/Button.css`
+
+After this optimization, other optimizations can still apply. For example, the `buttonFrom` and `buttonsFrom` exports from `Button.js` are unused too. The `usedExports` optimization will pick that up, and terser may be able to drop some statements from the module.
+
+Module concatenation also applies, so these four modules plus the entry module (and probably more dependencies) can be concatenated. **`index.js` ends up generating no code.**
+
+## Full example: understanding side effects with CSS files
+
+To better understand the impact of the `sideEffects` flag, let's look at a complete example of an npm package with CSS assets and how it might be affected during tree shaking. We'll create a fictional UI component library called "awesome-ui".
+
+### Package structure
+
+Our example package looks like this:
+
+```bash
+awesome-ui/
+├── package.json
+└── dist/
+    ├── index.js
+    ├── components/
+    │   ├── index.js
+    │   ├── Button/
+    │   │   ├── index.js
+    │   │   └── Button.css
+    │   ├── Card/
+    │   │   ├── index.js
+    │   │   └── Card.css
+    │   └── Modal/
+    │       ├── index.js
+    │       └── Modal.css
+    └── theme/
+        ├── index.js
+        └── defaultTheme.css
+```
+
+### Package file contents
+
+```json displayName="package.json"
+{
+  "name": "awesome-ui",
+  "version": "1.0.0",
+  "main": "dist/index.js",
+  "sideEffects": false
+}
+```
+
+```js displayName="dist/index.js"
+export * from './components';
+export * from './theme';
+```
+
+```js displayName="dist/components/index.js"
+export { default as Button } from './Button';
+export { default as Card } from './Card';
+export { default as Modal } from './Modal';
+```
+
+```js displayName="dist/components/Button/index.js"
+import './Button.css'; // This has a side effect - it applies styles when imported!
+
+export default function Button(props) {
+  // Button component implementation
+  return {
+    type: 'button',
+    ...props,
+  };
+}
+```
+
+```css displayName="dist/components/Button/Button.css"
+.awesome-ui-button {
+  background-color: #0078d7;
+  color: white;
+  padding: 8px 16px;
+  border-radius: 4px;
+  border: none;
+  cursor: pointer;
+}
+```
+
+`dist/components/Card/index.js` and `dist/components/Modal/index.js` would have a similar structure.
+
+```js displayName="dist/theme/index.js"
+import './defaultTheme.css'; // This has a side effect!
+
+export const themeColors = {
+  primary: '#0078d7',
+  secondary: '#f3f2f1',
+  danger: '#d13438',
+};
+```
+
+### What happens when consuming this package?
+
+Now, imagine a consumer application that only wants to use the Button component:
+
+```js
+import { Button } from 'awesome-ui';
+
+// Use the Button component
+```
+
+#### With `sideEffects: false` in `package.json`
+
+When webpack processes this import with tree shaking enabled:
+
+1. It sees the import for only `Button`.
+2. It looks at `package.json` and sees `sideEffects: false`.
+3. It determines it only needs to include the Button component code.
+4. Since all files are marked as having no side effects, it includes **only** the JavaScript code for the Button.
+5. **The CSS file import gets dropped!** Even though `Button.css` is imported in `Button/index.js`, webpack assumes this import has no side effects.
+
+The result: the Button component renders, but without any styling, because `Button.css` was eliminated during tree shaking.
+
+#### The correct configuration for this package
+
+To fix this, we need to update `package.json` to properly mark CSS files as having side effects:
+
+```json
+{
+  "name": "awesome-ui",
+  "version": "1.0.0",
+  "main": "dist/index.js",
+  "sideEffects": ["**/*.css"]
+}
+```
+
+With this configuration:
+
+1. webpack still identifies that only the Button component is needed.
+2. But now it recognizes that CSS files have side effects.
+3. So it includes `Button.css` when processing `Button/index.js`.
+
+### The decision tree for side effects
+
+Here's how webpack evaluates modules during tree shaking:
+
+1. Is the export from this module used, directly or indirectly?
+   - If yes: include the module.
+   - If no: continue to step 2.
+
+2. Is the module marked with side effects?
+   - If yes (`sideEffects` includes this file or is `true`): include the module.
+   - If no (`sideEffects` is `false` or doesn't include this file): exclude the module and its dependencies.
+
+For our library's files with the proper `sideEffects` configuration:
+
+- `dist/index.js`: No direct export used, no side effects -> skip over.
+- `dist/components/index.js`: No direct export used, no side effects -> skip over.
+- `dist/components/Button/index.js`: Direct export used -> include.
+- `dist/components/Button/Button.css`: No exports, has side effects -> include.
+- `dist/components/Card/*`: No exports used, no side effects -> exclude.
+- `dist/components/Modal/*`: No exports used, no side effects -> exclude.
+- `dist/theme/*`: No exports used, no side effects -> exclude.
+
+### Real-world impact
+
+The impact of an incorrect side-effects configuration can be significant:
+
+1. **CSS not being included**: components render without styles.
+2. **Global JavaScript not running**: polyfills or global configuration don't execute.
+3. **Initialization code skipped**: functions that register components or set up event listeners never run.
+
+These issues can be particularly hard to debug because they often appear only in production builds, when tree shaking is enabled.
+
+### Testing side-effects configuration
+
+A good way to test whether your side-effects configuration is correct:
+
+1. Create a minimal application that imports just one component.
+2. Build it with production settings (with tree shaking enabled).
+3. Check that all necessary styles and behaviors work correctly.
+4. Look at the generated bundle to confirm the right files are included.
+
+## Mark a function call as side-effect-free
+
+You can tell webpack that a function call is side-effect-free (pure) by using the `/*#__PURE__*/` annotation. Place it in front of a function call to mark it as side-effect-free. Arguments passed to the function are not marked by the annotation and may need to be marked individually. When the initial value in a variable declaration of an unused variable is considered side-effect-free (pure), it's marked as dead code, not executed, and dropped by the minimizer. This behavior is enabled when [`optimization.innerGraph`](#TODO[/configuration/optimization/#optimizationinnergraph]) is set to `true`.
+
+```js displayName="file.js"
+/* #__PURE__ */ double(55);
+```
+
+## Mark a function declaration as side-effect-free
+
+Available in webpack 5.107.0+.
+
+webpack also supports the [`#__NO_SIDE_EFFECTS__`](https://github.com/javascript-compiler-hints/compiler-notations-spec/blob/main/no-side-effects-notation-spec.md) annotation to mark a function declaration as pure. Calls to a function annotated this way can be eliminated from the bundle when their return value is unused, even if the function body isn't statically analyzable as pure. This is useful for factory or builder functions whose call sites would otherwise need a `/*#__PURE__*/` annotation each time.
+
+```js displayName="utils.js"
+/*#__NO_SIDE_EFFECTS__*/
+export function createLogger(prefix) {
+  return msg => console.log(`[${prefix}] ${msg}`);
+}
+```
+
+```js displayName="app.js"
+import { createLogger } from './utils';
+
+// dropped, because `createLogger` is annotated and its result is unused
+const unused = createLogger('debug');
+```
+
+> [!WARNING]
+> The annotation currently only takes effect within the module where it is declared. Cross-module propagation is planned for a future release.
+
+## Minify the output
+
+We've cued up our "dead code" to be dropped by using the `import` and `export` syntax, but we still need to actually remove it from the bundle. To do that, set the `mode` configuration option to [`production`](#TODO[/configuration/mode/#mode-production]).
+
+```diff displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    filename: 'bundle.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+- mode: 'development',
+- optimization: {
+-   usedExports: true,
+- }
++ mode: 'production',
+};
+```
+
+> [!TIP]
+> Note that the `--optimize-minimize` flag can also be used to enable `TerserPlugin`.
+
+With that squared away, run `npm run build` again and see what's changed.
+
+Notice anything different about `dist/bundle.js`? The whole bundle is now minified and mangled, but if you look carefully, you won't see the `square` function — only a mangled version of the `cube` function (`function r(e){return e*e*e}n.a=r`). With minification and tree shaking, our bundle is now a few bytes smaller. That may not seem like much in this contrived example, but tree shaking can yield a significant decrease in bundle size when working on larger applications with complex dependency trees.
+
+> [!TIP]
+> [`ModuleConcatenationPlugin`](#TODO[/plugins/module-concatenation-plugin/]) is required for tree shaking to work. It's added by `mode: 'production'`. If you're not using that mode, remember to add [`ModuleConcatenationPlugin`](#TODO[/plugins/module-concatenation-plugin/]) manually.
+
+## Common pitfalls with side effects
+
+When working with tree shaking and the `sideEffects` flag, there are several common pitfalls to avoid.
+
+### 1. Over-optimistic `sideEffects: false`
+
+Setting `sideEffects: false` in your `package.json` is tempting for optimal tree shaking, but it can cause problems if your code actually does have side effects. Examples of hidden side effects:
+
+- CSS imports (as demonstrated above)
+- Polyfills that modify global objects
+- Libraries that register global event listeners
+- Code that modifies prototype chains
+
+### 2. Re-exports with side effects
+
+Consider this pattern:
+
+```js
+// This file has side effects that might be skipped
+import './polyfill';
+
+// Re-export components
+export * from './components';
+```
+
+If a consumer only imports specific components, the polyfill import might be skipped entirely if it isn't properly marked with side effects.
+
+### 3. Forgetting about nested dependencies
+
+Your package might correctly mark its side effects, but if it depends on third-party packages that mark their side effects incorrectly, you may still run into issues.
+
+### 4. Testing only in development mode
+
+Tree shaking typically only fully activates in production mode. Testing only in development can hide tree shaking issues until deployment.
+
+## Conclusion
+
+What we've learned is that, to take advantage of _tree shaking_, you must:
+
+- Use ES2015 module syntax (`import` and `export`).
+- Ensure no compiler transforms your ES2015 module syntax into CommonJS modules. (This is the default behavior of the popular Babel preset `@babel/preset-env` — see the [documentation](https://babeljs.io/docs/en/babel-preset-env#modules) for details.)
+- Add a `"sideEffects"` property to your project's `package.json` file.
+- Be careful to correctly mark files with side effects, especially CSS imports.
+- Use the [`production`](#TODO[/configuration/mode/#mode-production]) `mode` configuration option to enable [various optimizations](#TODO[/configuration/mode/#usage]), including minification and tree shaking. (Side-effects optimization is enabled in development mode using the flag value.)
+- Set a correct value for [`devtool`](#TODO[/configuration/devtool/#devtool]), as some of them can't be used in `production` mode.
+
+You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves consumed by autumn. To get rid of the dead leaves, you have to shake the tree, causing them to fall.
+
+If you're interested in more ways to optimize your output, head to the next guide for details on building for [production](#TODO[/guides/production]).
+
+## Further reading
+
+- [Debugging Optimization Bailouts](https://webpack.js.org/plugins/module-concatenation-plugin/#debugging-optimization-bailouts)
+- [Issue 6074 - Add support for more complex selectors for sideEffects](https://github.com/webpack/webpack/issues/6074)
diff --git a/pages/guides/site.json b/pages/guides/site.json
new file mode 100644
index 00000000..c217ed35
--- /dev/null
+++ b/pages/guides/site.json
@@ -0,0 +1,209 @@
+{
+  "sidebar": [
+    {
+      "groupName": "Getting Started",
+      "items": [
+        { "link": "/guides/getting-started", "label": "Getting Started" },
+        {
+          "link": "/guides/getting-started/installing-webpack",
+          "label": "Installing webpack"
+        },
+        {
+          "label": "Concepts",
+          "items": [
+            { "link": "/guides/getting-started/concepts", "label": "Overview" },
+            {
+              "link": "/guides/getting-started/concepts/why-webpack",
+              "label": "Why webpack"
+            },
+            {
+              "link": "/guides/getting-started/concepts/modules",
+              "label": "Modules"
+            },
+            {
+              "link": "/guides/getting-started/concepts/dependency-graph",
+              "label": "Dependency Graph"
+            },
+            {
+              "link": "/guides/getting-started/concepts/entry-points",
+              "label": "Entry Points"
+            },
+            {
+              "link": "/guides/getting-started/concepts/output",
+              "label": "Output"
+            },
+            {
+              "link": "/guides/getting-started/concepts/loaders",
+              "label": "Loaders"
+            },
+            {
+              "link": "/guides/getting-started/concepts/plugins",
+              "label": "Plugins"
+            },
+            {
+              "link": "/guides/getting-started/concepts/configuration",
+              "label": "Configuration"
+            },
+            {
+              "link": "/guides/getting-started/concepts/module-resolution",
+              "label": "Module Resolution"
+            },
+            {
+              "link": "/guides/getting-started/concepts/targets",
+              "label": "Targets"
+            },
+            {
+              "link": "/guides/getting-started/concepts/manifest",
+              "label": "The Manifest"
+            },
+            {
+              "link": "/guides/getting-started/concepts/hot-module-replacement",
+              "label": "Hot Module Replacement"
+            },
+            {
+              "link": "/guides/getting-started/concepts/module-federation",
+              "label": "Module Federation"
+            },
+            {
+              "link": "/guides/getting-started/concepts/under-the-hood",
+              "label": "Under the Hood"
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "groupName": "Core Workflows",
+      "items": [
+        {
+          "link": "/guides/core-workflows/asset-management",
+          "label": "Asset Management"
+        },
+        {
+          "link": "/guides/core-workflows/asset-modules",
+          "label": "Asset Modules"
+        },
+        {
+          "link": "/guides/core-workflows/output-management",
+          "label": "Output Management"
+        },
+        {
+          "label": "Development",
+          "items": [
+            {
+              "link": "/guides/core-workflows/development",
+              "label": "Overview"
+            },
+            {
+              "link": "/guides/core-workflows/development/hot-module-replacement",
+              "label": "Hot Module Replacement"
+            },
+            {
+              "link": "/guides/core-workflows/development/vagrant",
+              "label": "Vagrant"
+            }
+          ]
+        },
+        { "link": "/guides/core-workflows/production", "label": "Production" },
+        {
+          "link": "/guides/core-workflows/environment-variables",
+          "label": "Environment Variables"
+        }
+      ]
+    },
+    {
+      "groupName": "Optimization",
+      "items": [
+        {
+          "label": "Code Splitting",
+          "items": [
+            {
+              "link": "/guides/optimization/code-splitting",
+              "label": "Overview"
+            },
+            {
+              "link": "/guides/optimization/code-splitting/lazy-loading",
+              "label": "Lazy Loading"
+            }
+          ]
+        },
+        { "link": "/guides/optimization/caching", "label": "Caching" },
+        {
+          "link": "/guides/optimization/tree-shaking",
+          "label": "Tree Shaking"
+        },
+        {
+          "link": "/guides/optimization/build-performance",
+          "label": "Build Performance"
+        }
+      ]
+    },
+    {
+      "groupName": "Modern Web Platform",
+      "items": [
+        { "link": "/guides/modern-web", "label": "Overview" },
+        { "link": "/guides/modern-web/native-css", "label": "Native CSS" },
+        {
+          "link": "/guides/modern-web/progressive-web-application",
+          "label": "Progressive Web Application"
+        },
+        { "link": "/guides/modern-web/web-workers", "label": "Web Workers" }
+      ]
+    },
+    {
+      "groupName": "Modules & Dependencies",
+      "items": [
+        {
+          "link": "/guides/modules-and-dependencies/ecma-script-modules",
+          "label": "ECMAScript Modules"
+        },
+        {
+          "link": "/guides/modules-and-dependencies/package-exports",
+          "label": "Package Exports"
+        },
+        {
+          "link": "/guides/modules-and-dependencies/dependency-management",
+          "label": "Dependency Management"
+        },
+        {
+          "link": "/guides/modules-and-dependencies/entry-advanced",
+          "label": "Advanced Entry"
+        },
+        {
+          "link": "/guides/modules-and-dependencies/shimming",
+          "label": "Shimming"
+        }
+      ]
+    },
+    {
+      "groupName": "Tooling & Integration",
+      "items": [
+        {
+          "link": "/guides/tooling-and-integration/typescript",
+          "label": "TypeScript"
+        },
+        {
+          "link": "/guides/tooling-and-integration/authoring-libraries",
+          "label": "Authoring Libraries"
+        },
+        {
+          "link": "/guides/tooling-and-integration/content-security-policy",
+          "label": "Content Security Policies"
+        },
+        {
+          "link": "/guides/tooling-and-integration/integrations",
+          "label": "Integrations"
+        }
+      ]
+    },
+    {
+      "groupName": "Migration",
+      "items": [
+        { "link": "/guides/migration", "label": "Overview" },
+        { "link": "/guides/migration/to-v3", "label": "To v2 or v3 from v1" },
+        { "link": "/guides/migration/to-v4", "label": "To v4 from v3" },
+        { "link": "/guides/migration/to-v5", "label": "To v5 from v4" }
+      ]
+    }
+  ]
+}
diff --git a/pages/guides/tooling-and-integration/authoring-libraries.md b/pages/guides/tooling-and-integration/authoring-libraries.md
new file mode 100644
index 00000000..c7eff7fd
--- /dev/null
+++ b/pages/guides/tooling-and-integration/authoring-libraries.md
@@ -0,0 +1,318 @@
+---
+authors: pksjce,johnstew,simon04,5angel,marioacc,byzyk,EugeneHlushko,AnayaDesign,chenxsan,wizardofhogwarts,Debraj2024,avivkeller
+---
+
+# Authoring Libraries
+
+In addition to applications, webpack can bundle JavaScript libraries. This guide is aimed at library authors who want to streamline how they bundle and distribute their code.
+
+## Authoring a library
+
+Suppose we are building a small library called `webpack-numbers` that converts the numbers 1 through 5 between their numeric and textual representations, for example turning `2` into `'two'`.
+
+The basic project layout looks like this:
+
+```diff
++ ├── webpack.config.js
++ ├── package.json
++ └── /src
++     ├── index.js
++     └── ref.json
+```
+
+Initialize the project with npm, then install `webpack`, `webpack-cli`, and `lodash` as development dependencies:
+
+```bash
+npm init -y
+npm install --save-dev webpack webpack-cli lodash
+```
+
+We install `lodash` as a `devDependency` because, to start with, we will bundle it directly into our library. Since it ends up in the final output, consumers of the library won't need to install it themselves.
+
+```json displayName="src/ref.json"
+[
+  {
+    "num": 1,
+    "word": "One"
+  },
+  {
+    "num": 2,
+    "word": "Two"
+  },
+  {
+    "num": 3,
+    "word": "Three"
+  },
+  {
+    "num": 4,
+    "word": "Four"
+  },
+  {
+    "num": 5,
+    "word": "Five"
+  },
+  {
+    "num": 0,
+    "word": "Zero"
+  }
+]
+```
+
+```js displayName="src/index.js"
+import _ from 'lodash';
+import numRef from './ref.json';
+
+export function numToWord(num) {
+  return _.reduce(
+    numRef,
+    (accum, ref) => (ref.num === num ? ref.word : accum),
+    ''
+  );
+}
+
+export function wordToNum(word) {
+  return _.reduce(
+    numRef,
+    (accum, ref) => (ref.word === word && word.toLowerCase() ? ref.num : accum),
+    -1
+  );
+}
+```
+
+## webpack configuration
+
+Let's begin with this basic webpack configuration:
+
+```js displayName="webpack.config.js"
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+export default {
+  entry: './src/index.js',
+  output: {
+    path: path.resolve(__dirname, 'dist'),
+    filename: 'webpack-numbers.js',
+  },
+};
+```
+
+In this example, we tell webpack to bundle `src/index.js` into `dist/webpack-numbers.js`.
+
+### Adding source maps
+
+When bundling a library, it's a good idea to generate source maps. They let consumers debug against your original source code instead of the minified bundle. You can enable them with the [`devtool`](#TODO[/configuration/devtool/]) option:
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: './src/index.js',
++   devtool: 'source-map',
+    output: {
+      path: path.resolve(__dirname, 'dist'),
+      filename: 'webpack-numbers.js',
+    },
+  };
+```
+
+> [!TIP]
+> Setting `devtool` to `'source-map'` generates a separate `.map` file alongside your bundle. Be sure to publish this `.map` file too, so consumers can use it for debugging.
+
+## Expose the library
+
+So far this matches how you'd bundle an application. Here's where things differ: we need to expose the entry point's exports through the [`output.library`](#TODO[/configuration/output/#outputlibrary]) option.
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: './src/index.js',
+    output: {
+      path: path.resolve(__dirname, 'dist'),
+      filename: 'webpack-numbers.js',
++     library: 'webpackNumbers',
+    },
+  };
+```
+
+We exposed the entry point as `webpackNumbers` so it can be used through a script tag:
+
+```html
+<script src="https://example.org/webpack-numbers.js"></script>
+<script>
+  window.webpackNumbers.wordToNum('Five');
+</script>
+```
+
+However, this only works when the library is referenced through a script tag. It can't be consumed in other environments such as CommonJS, AMD, or Node.js.
+
+As library authors, we want our library to work across different environments. In other words, users should be able to consume it in all of the following ways:
+
+- **CommonJS module require**:
+
+  ```js
+  const webpackNumbers = require('webpack-numbers');
+
+  // ...
+  webpackNumbers.wordToNum('Two');
+  ```
+
+- **AMD module require**:
+
+  ```js
+  require(['webpackNumbers'], webpackNumbers => {
+    // ...
+    webpackNumbers.wordToNum('Two');
+  });
+  ```
+
+- **script tag**:
+
+  ```html
+  <!DOCTYPE html>
+  <html>
+    ...
+    <script src="https://example.org/webpack-numbers.js"></script>
+    <script>
+      // ...
+      // Global variable
+      webpackNumbers.wordToNum('Five');
+      // Property in the window object
+      window.webpackNumbers.wordToNum('Five');
+      // ...
+    </script>
+  </html>
+  ```
+
+To support all of these, update the `output.library` option and set its `type` to [`'umd'`](#TODO[/configuration/output/#type-umd]):
+
+```diff displayName="webpack.config.js"
+ import path from 'node:path';
+ import { fileURLToPath } from 'node:url';
+
+ const __filename = fileURLToPath(import.meta.url);
+ const __dirname = path.dirname(__filename);
+
+ export default {
+   entry: './src/index.js',
+   output: {
+     path: path.resolve(__dirname, 'dist'),
+     filename: 'webpack-numbers.js',
+-    library: 'webpackNumbers',
++    globalObject: 'this',
++    library: {
++      name: 'webpackNumbers',
++      type: 'umd',
++    },
+   },
+ };
+```
+
+Now webpack produces a library that works with CommonJS, AMD, and a script tag.
+
+> [!TIP]
+> Note that the `library` setup is tied to the `entry` configuration. For most libraries, a single entry point is enough. While [multi-part libraries](https://github.com/webpack/webpack/tree/master/examples/multi-part-library) are possible, it's simpler to expose partial exports through an [index script](https://stackoverflow.com/questions/34072598/es6-exporting-importing-in-index-file) that acts as a single entry point. Using an `array` as the `entry` for a library is **not recommended**.
+
+## Externalize lodash
+
+If you run `npx webpack` now, you'll notice the resulting bundle is fairly large. Inspecting the file reveals that lodash has been bundled along with your code. To avoid bundling `lodash` and bloating the library, we can configure webpack to treat it as an external module. Because we're no longer bundling it, the consumer is responsible for providing it, so you should move `lodash` from `devDependencies` to `dependencies` (or `peerDependencies`) so package managers install it automatically for your library's consumers.
+
+This is done with the [`externals`](#TODO[/configuration/externals/]) configuration:
+
+```diff displayName="webpack.config.js"
+  import path from 'node:path';
+  import { fileURLToPath } from 'node:url';
+
+  const __filename = fileURLToPath(import.meta.url);
+  const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: './src/index.js',
+    output: {
+      path: path.resolve(__dirname, 'dist'),
+      filename: 'webpack-numbers.js',
+      library: {
+        name: 'webpackNumbers',
+        type: 'umd',
+      },
+    },
++   externals: {
++     lodash: {
++       commonjs: 'lodash',
++       commonjs2: 'lodash',
++       amd: 'lodash',
++       root: '_',
++     },
++   },
+  };
+```
+
+This tells webpack that your library expects a dependency named `lodash` to be available in the consumer's environment.
+
+### External limitations
+
+For libraries that import several files from a single dependency:
+
+```js
+import A from 'library/one';
+import B from 'library/two';
+
+// ...
+```
+
+You won't be able to exclude them from the bundle by listing `library` in `externals`. You'll need to exclude them individually, or with a regular expression:
+
+```js
+export default {
+  // ...
+  externals: [
+    'library/one',
+    'library/two',
+    // Everything that starts with "library/"
+    /^library\/.+$/,
+  ],
+};
+```
+
+## Final steps
+
+Optimize your output for production by following the steps in the [production guide](#TODO[/guides/production]). Let's also point the package's `main` field in `package.json` at your generated bundle:
+
+```json displayName="package.json"
+{
+  ...
+  "main": "dist/webpack-numbers.js",
+  ...
+}
+```
+
+Or, to add it as a standard module per [this guide](https://github.com/dherman/defense-of-dot-js/blob/master/proposal.md#typical-usage):
+
+```json displayName="package.json"
+{
+  ...
+  "module": "src/index.js",
+  ...
+}
+```
+
+The `main` key refers to the [standard from `package.json`](https://docs.npmjs.com/files/package.json#main), while `module` refers to [a](https://github.com/dherman/defense-of-dot-js/blob/master/proposal.md) [proposal](https://github.com/rollup/rollup/wiki/pkg.module) that lets the JavaScript ecosystem adopt ES2015 modules without breaking backwards compatibility.
+
+> [!WARNING]
+> The `module` property should point to a script that uses ES2015 module syntax but no other syntax features that browsers or Node.js don't yet support. This lets webpack parse the module syntax itself, enabling lighter bundles through [tree shaking](https://webpack.js.org/guides/tree-shaking/) when users consume only certain parts of the library.
+
+You can now [publish it as an npm package](https://docs.npmjs.com/getting-started/publishing-npm-packages) and find it on [unpkg.com](https://unpkg.com/#/) to distribute it to your users.
+
+> [!TIP]
+> To expose stylesheets associated with your library, use the [`MiniCssExtractPlugin`](#TODO[/plugins/mini-css-extract-plugin]). Users can then consume and load them as they would any other stylesheet.
diff --git a/pages/guides/tooling-and-integration/content-security-policy.md b/pages/guides/tooling-and-integration/content-security-policy.md
new file mode 100644
index 00000000..e0b4abed
--- /dev/null
+++ b/pages/guides/tooling-and-integration/content-security-policy.md
@@ -0,0 +1,40 @@
+---
+authors: EugeneHlushko,probablyup,wizardofhogwarts,koto,avivkeller
+---
+
+# Content Security Policies
+
+webpack can add a `nonce` to every script it loads. To enable this, assign a value to the `__webpack_nonce__` variable inside your entry script. webpack then generates and applies a unique hash-based `nonce` for each page view. This is why `__webpack_nonce__` belongs in the entry file rather than in your configuration. Note that `__webpack_nonce__` must always be a base64-encoded string.
+
+## Examples
+
+In the entry file:
+
+```js
+// ...
+__webpack_nonce__ = 'c29tZSBjb29sIHN0cmluZyB3aWxsIHBvcCB1cCAxMjM=';
+// ...
+```
+
+## Enabling CSP
+
+Content Security Policies are not enabled by default. To turn one on, the document must be served with a `Content-Security-Policy` header or a `<meta http-equiv="Content-Security-Policy" ...>` tag that instructs the browser to enforce the policy. Here is an example of a CSP header that also allow-lists a CDN URL:
+
+```html
+Content-Security-Policy: default-src 'self'; script-src 'self'
+https://trusted.cdn.com;
+```
+
+For more details on CSP and the `nonce` attribute, see the Further reading section at the bottom of this page.
+
+## Trusted Types
+
+webpack can also use Trusted Types to load dynamically constructed scripts, allowing it to comply with the [`require-trusted-types-for`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for) CSP directive. See the [`output.trustedTypes`](#TODO[/configuration/output/#outputtrustedtypes]) configuration option.
+
+## Further reading
+
+- [Nonce purpose explained](https://stackoverflow.com/questions/42922784/what-s-the-purpose-of-the-html-nonce-attribute-for-script-and-style-elements)
+- [On the Insecurity of Whitelists and the Future of Content Security Policy](https://ai.google/research/pubs/pub45542)
+- [Locking Down Your Website Scripts with CSP, Hashes, Nonces and Report URI](https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/)
+- [CSP on MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
+- [Trusted Types](https://web.dev/trusted-types)
diff --git a/pages/guides/tooling-and-integration/integrations.md b/pages/guides/tooling-and-integration/integrations.md
new file mode 100644
index 00000000..61e4b7bf
--- /dev/null
+++ b/pages/guides/tooling-and-integration/integrations.md
@@ -0,0 +1,116 @@
+---
+authors: pksjce,bebraw,tashian,skipjack,AnayaDesign,avivkeller
+---
+
+# Integrations
+
+Let's start by clearing up a common misconception. webpack is a module bundler like [Browserify](http://browserify.org/) or [Brunch](https://brunch.io/). It is _not_ a task runner like [Make](https://www.gnu.org/software/make/), [Grunt](https://gruntjs.com/), or [Gulp](https://gulpjs.com/). Task runners automate common development tasks such as linting, building, or testing your project. Compared with bundlers, task runners operate at a higher level. You can still benefit from their higher-level tooling while leaving the problem of bundling to webpack.
+
+Bundlers help you prepare your JavaScript and stylesheets for deployment, transforming them into a format suitable for the browser. For example, JavaScript can be [minified](#TODO[/plugins/minimizer-webpack-plugin/]) or [split into chunks](#TODO[/guides/code-splitting]) and [lazy-loaded](#TODO[/guides/lazy-loading]) to improve performance. Bundling is one of the most important challenges in web development, and solving it well removes a great deal of pain from the process.
+
+The good news is that, although there is some overlap, task runners and bundlers can work well together when approached the right way. This guide provides a high-level overview of how webpack can be integrated into some of the more popular task runners.
+
+## npm scripts
+
+webpack users often use npm [`scripts`](https://docs.npmjs.com/misc/scripts) as their task runner. This is a good starting point. Cross-platform support can become a problem, but there are several workarounds. Many — perhaps most — users get by with npm `scripts` and various levels of webpack configuration and tooling.
+
+So while webpack's core focus is bundling, a variety of extensions can enable you to use it for jobs typical of a task runner. Integrating a separate tool adds complexity, so weigh the pros and cons before proceeding.
+
+## Grunt
+
+For those using Grunt, we recommend the [`grunt-webpack`](https://www.npmjs.com/package/grunt-webpack) package. With `grunt-webpack`, you can run webpack or [webpack-dev-server](https://github.com/webpack/webpack-dev-server) as a task, access stats within [template tags](https://gruntjs.com/api/grunt.template), split development and production configurations, and more. Start by installing `grunt-webpack` as well as `webpack` itself if you haven't already:
+
+```bash
+npm install --save-dev grunt-webpack webpack
+```
+
+Then register a configuration and load the task:
+
+```js displayName="Gruntfile.js"
+const webpackConfig = require('./webpack.config.js');
+
+module.exports = function (grunt) {
+  grunt.initConfig({
+    webpack: {
+      options: {
+        stats: !process.env.NODE_ENV || process.env.NODE_ENV === 'development',
+      },
+      prod: webpackConfig,
+      dev: { watch: true, ...webpackConfig },
+    },
+  });
+
+  grunt.loadNpmTasks('grunt-webpack');
+};
+```
+
+For more information, see the [repository](https://github.com/danez/grunt-webpack).
+
+## Gulp
+
+Gulp is also a fairly straightforward integration with the help of the [`webpack-stream`](https://github.com/shama/webpack-stream) package (a.k.a. `gulp-webpack`). In this case, there is no need to install `webpack` separately, since it is a direct dependency of `webpack-stream`:
+
+```bash
+npm install --save-dev webpack-stream
+```
+
+You can `require('webpack-stream')` instead of `webpack` and optionally pass it a configuration:
+
+```js displayName="gulpfile.js"
+import gulp from 'gulp';
+import webpack from 'webpack-stream';
+
+gulp.task('default', () =>
+  gulp
+    .src('src/entry.js')
+    .pipe(
+      webpack({
+        // Any configuration options...
+      })
+    )
+    .pipe(gulp.dest('dist/'))
+);
+```
+
+For more information, see the [repository](https://github.com/shama/webpack-stream).
+
+## Mocha
+
+The [`mocha-webpack`](https://github.com/zinserjan/mocha-webpack) utility provides a clean integration with Mocha. The repository covers the pros and cons in more detail, but essentially `mocha-webpack` is a simple wrapper that offers almost the same CLI as Mocha itself, along with various webpack features such as an improved watch mode and better path resolution. Here's a small example of how to install it and use it to run a test suite found within `./test`:
+
+```bash
+npm install --save-dev webpack mocha mocha-webpack
+mocha-webpack 'test/**/*.js'
+```
+
+For more information, see the [repository](https://github.com/zinserjan/mocha-webpack).
+
+## Karma
+
+The [`karma-webpack`](https://github.com/webpack-contrib/karma-webpack) package lets you use webpack to pre-process files in [Karma](https://karma-runner.github.io/1.0/index.html).
+
+```bash
+npm install --save-dev webpack karma karma-webpack
+```
+
+```js displayName="karma.conf.js"
+export default function (config) {
+  config.set({
+    frameworks: ['webpack'],
+    files: [
+      { pattern: 'test/*_test.js', watched: false },
+      { pattern: 'test/**/*_test.js', watched: false },
+    ],
+    preprocessors: {
+      'test/*_test.js': ['webpack'],
+      'test/**/*_test.js': ['webpack'],
+    },
+    webpack: {
+      // Any custom webpack configuration...
+    },
+    plugins: ['karma-webpack'],
+  });
+}
+```
+
+For more information, see the [repository](https://github.com/webpack-contrib/karma-webpack).
diff --git a/pages/guides/tooling-and-integration/typescript.md b/pages/guides/tooling-and-integration/typescript.md
new file mode 100644
index 00000000..9be1ec4c
--- /dev/null
+++ b/pages/guides/tooling-and-integration/typescript.md
@@ -0,0 +1,360 @@
+---
+authors: morsdyce,kkamali,mtrivera,byzyk,EugeneHlushko,chenxsan,snitin315,tusharthakur04,ThierryRakotomanana,valentina-buoro,avivkeller
+---
+
+# TypeScript
+
+> [!TIP]
+> This guide builds on the [Getting Started](#TODO[/guides/getting-started/]) guide.
+
+[TypeScript](https://www.typescriptlang.org) is a typed superset of JavaScript that compiles to plain JavaScript. In this guide, we'll learn how to integrate TypeScript with webpack.
+
+## Basic setup
+
+First, install the TypeScript compiler and loader:
+
+```bash
+npm install --save-dev typescript ts-loader
+```
+
+Now we'll modify the directory structure and configuration files:
+
+```diff displayName="project"
+ webpack-demo
+  ├── package.json
+  ├── package-lock.json
++ ├── tsconfig.json
+- ├── webpack.config.js
++ ├── webpack.config.ts
+  ├── /dist
+  │   ├── bundle.js
+  │   └── index.html
+  ├── /src
+- │   ├── index.js
++ │   └── index.ts
+  └── /node_modules
+```
+
+Let's set up a configuration that supports JSX and compiles TypeScript down to ES5:
+
+```json displayName="tsconfig.json"
+{
+  "compilerOptions": {
+    "outDir": "./dist/",
+    "noImplicitAny": true,
+    "module": "esnext",
+    "moduleResolution": "bundler",
+    "target": "esnext",
+    "jsx": "react-jsx",
+    "allowJs": true
+  },
+  "include": ["src/**/*"],
+  "exclude": ["node_modules"]
+}
+```
+
+See [TypeScript's documentation](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) to learn more about `tsconfig.json` configuration options. To learn more about webpack configuration, see the [configuration concepts](#TODO[/concepts/configuration/]).
+
+Now let's configure webpack to handle TypeScript. First, install the required dependencies:
+
+```bash
+npm install --save-dev ts-node @types/node
+```
+
+```ts displayName="webpack.config.ts"
+import path from 'node:path';
+import { fileURLToPath } from 'url';
+import webpack from 'webpack';
+
+// in case you run into any TypeScript error when configuring `devServer`
+import 'webpack-dev-server';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+const config: webpack.Configuration = {
+  entry: './src/index.ts',
+  module: {
+    rules: [
+      {
+        test: /\.tsx?$/,
+        use: 'ts-loader',
+        exclude: /node_modules/,
+      },
+    ],
+  },
+  resolve: {
+    extensions: ['.tsx', '.ts', '.js'],
+  },
+  output: {
+    filename: 'bundle.js',
+    path: path.resolve(__dirname, 'dist'),
+  },
+};
+
+export default config;
+```
+
+> [!NOTE]
+> For more on how to write configuration in a [TypeScript file](#TODO[https://webpack.js.org/configuration/configuration-languages/#typescript]).
+
+This directs webpack to _enter_ through `./index.ts`, _load_ all `.ts` and `.tsx` files through `ts-loader`, and _output_ a `bundle.js` file in our current directory.
+
+Next, we need to adjust how we import `lodash` in `./index.ts`. Since the lodash definitions don't include a default export, we'll need to update our import statement. First, make sure to install the [TypeScript definitions](#using-third-party-libraries):
+
+```bash
+npm install --save-dev @types/lodash
+```
+
+Then update the import at the top of the file:
+
+```diff displayName="./index.ts"
+- import _ from 'lodash';
++ import * as _ from 'lodash';
+
+  function component() {
+    const element = document.createElement('div');
+
+    element.innerHTML = _.join(['Hello', 'webpack'], ' ');
+
+    return element;
+  }
+
+  document.body.appendChild(component());
+```
+
+> [!TIP]
+> To make imports work this way by default and keep the `import _ from 'lodash';` syntax in TypeScript, set `"allowSyntheticDefaultImports": true` and `"esModuleInterop": true` in your **tsconfig.json** file. This relates to TypeScript configuration and is mentioned here only for your information.
+
+## Ways to use TypeScript in `webpack.config.ts`
+
+There are three ways to use TypeScript in `webpack.config.ts`:
+
+1. **Using webpack with Node.js's built-in type-stripping feature (recommended):**
+
+   ```bash
+   webpack -c ./webpack.config.ts
+   ```
+
+   webpack attempts to load the configuration using Node.js's built-in [type stripping](https://nodejs.org/api/typescript.html#type-stripping), then falls back to loading the configuration file using `interpret` and `rechoir` (in which case you need to install `tsx`, `ts-node`, or another tool).
+
+2. **Using a custom `--import`/`--require` for Node.js:**
+
+   ```bash
+   NODE_OPTIONS='--import=tsx --no-experimental-strip-types'  webpack -c ./webpack.config.ts
+   ```
+
+   ```bash
+   NODE_OPTIONS='--require=ts-node/register --no-experimental-strip-types'  webpack -c ./webpack.config.ts
+   ```
+
+   > [!NOTE]
+   > The `--no-experimental-strip-types` flag is required starting with Node.js version 22.7.0.
+
+3. **Using Node.js's built-in transform-types feature for Node.js >= v22.7.0:**
+
+   Use this to enable transformation of non-erasable TypeScript syntax, which requires JavaScript code generation, such as enum declarations and parameter properties.
+
+   ```bash
+   NODE_OPTIONS='--experimental-transform-types' webpack --disable-interpret -c ./webpack.config.ts
+   ```
+
+## TypeScript path aliases
+
+Available in webpack 5.105.0+.
+
+If you use [`compilerOptions.paths`](https://www.typescriptlang.org/tsconfig#paths) or `compilerOptions.baseUrl` in your `tsconfig.json` to create import aliases, then starting with webpack 5.105, webpack can read these aliases directly via [`resolve.tsconfig`](#TODO[/configuration/resolve/#resolvetsconfig]). This replaces [`tsconfig-paths-webpack-plugin`](https://www.npmjs.com/package/tsconfig-paths-webpack-plugin), which should no longer be used.
+
+`resolve.tsconfig` accepts `boolean | string | object`:
+
+```js displayName="webpack.config.ts"
+export default {
+  resolve: {
+    tsconfig: true, // automatically find tsconfig.json
+  },
+};
+```
+
+Pass a string to point at a specific file (useful in monorepos):
+
+```js
+export default {
+  resolve: {
+    tsconfig: './tsconfig.app.json',
+  },
+};
+```
+
+Pass an object to also resolve [TypeScript project references](https://www.typescriptlang.org/docs/handbook/project-references.html):
+
+```js
+export default {
+  resolve: {
+    tsconfig: {
+      configFile: './tsconfig.json',
+      references: 'auto', // inherit references from tsconfig, or pass an array of paths
+    },
+  },
+};
+```
+
+```json displayName="tsconfig.json"
+{
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": {
+      "@/*": ["src/*"]
+    }
+  }
+}
+```
+
+With the above, `@/components/Button` resolves to `src/components/Button` without any additional plugins or duplicating aliases in `resolve.alias`.
+
+### Migrating from `tsconfig-paths-webpack-plugin`
+
+If you're currently using `tsconfig-paths-webpack-plugin`, you can drop it in favor of the built-in `resolve.tsconfig` option:
+
+```diff
+- import TsconfigPathsPlugin from 'tsconfig-paths-webpack-plugin';
+
+  export default {
+    resolve: {
+-     plugins: [new TsconfigPathsPlugin()],
++     // Auto-find tsconfig.json in the project root
++     tsconfig: true,
++
++     // Or explicitly point to one
++     // tsconfig: './tsconfig.app.json'
+    },
+  };
+```
+
+You can then remove the package from your project:
+
+```bash
+npm uninstall tsconfig-paths-webpack-plugin
+```
+
+> [!WARNING]
+> `resolve.tsconfig` only handles module resolution — it does not transpile TypeScript. You still need `ts-loader`, `babel-loader` with `@babel/preset-typescript`, or another transpilation step.
+
+## Loader
+
+[`ts-loader`](https://github.com/TypeStrong/ts-loader)
+
+We use `ts-loader` in this guide because it makes enabling additional webpack features, such as importing other web assets, a bit easier.
+
+> [!WARNING]
+> `ts-loader` uses `tsc`, the TypeScript compiler, and relies on your `tsconfig.json` configuration. Be sure to avoid setting [`module`](https://www.typescriptlang.org/tsconfig#module) to "CommonJS", or webpack won't be able to [tree-shake your code](#TODO[/guides/tree-shaking]).
+
+Note that if you're already using [`babel-loader`](https://github.com/babel/babel-loader) to transpile your code, you can use [`@babel/preset-typescript`](https://babeljs.io/docs/en/babel-preset-typescript) and let Babel handle both your JavaScript and TypeScript files instead of using an additional loader. Keep in mind that, unlike `ts-loader`, the underlying [`@babel/plugin-transform-typescript`](https://babeljs.io/docs/en/babel-plugin-transform-typescript) plugin does not perform any type checking.
+
+## Source maps
+
+To learn more about source maps, see the [development guide](#TODO[/guides/development]).
+
+To enable source maps, we must configure TypeScript to output inline source maps to our compiled JavaScript files. The following line must be added to our TypeScript configuration:
+
+```diff displayName="tsconfig.json"
+  {
+    "compilerOptions": {
+      "outDir": "./dist/",
++     "sourceMap": true,
+      "noImplicitAny": true,
+      "module": "esnext",
+      "moduleResolution": "bundler",
+      "target": "esnext",
+      "jsx": "react-jsx",
+      "allowJs": true,
+  },
+    "include": ["src/**/*"],
+    "exclude": ["node_modules"]
+  }
+```
+
+Now we need to tell webpack to extract these source maps and include them in our final bundle:
+
+```diff displayName="webpack.config.ts"
+ import path from "node:path";
+ import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+  export default {
+    entry: './src/index.ts',
++   devtool: 'inline-source-map',
+    module: {
+      rules: [
+        {
+          test: /\.tsx?$/,
+          use: 'ts-loader',
+          exclude: /node_modules/,
+        },
+      ],
+    },
+    resolve: {
+      extensions: [ '.tsx', '.ts', '.js' ],
+    },
+    output: {
+      filename: 'bundle.js',
+      path: path.resolve(__dirname, 'dist'),
+    },
+  };
+```
+
+See the [devtool documentation](#TODO[/configuration/devtool/]) for more information.
+
+## Client types
+
+You can use webpack-specific features in your TypeScript code, such as [`import.meta.webpack`](#TODO[/api/module-variables/#importmetawebpack]). webpack also provides types for them. Add a TypeScript [`reference`](https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-) directive to declare it:
+
+```ts
+/// <reference types="webpack/module" />
+console.log(import.meta.webpack); // without the reference declared above, TypeScript will throw an error
+```
+
+To enable the types for the whole project, add `webpack/module` to `compilerOptions.types` in `tsconfig.json`:
+
+```diff
+  {
+    "compilerOptions": {
+      "types": [
++       "webpack/module"
+      ]
+    }
+  }
+```
+
+## Using third-party libraries
+
+When installing third-party libraries from npm, remember to also install the typing definitions for that library.
+
+For example, to use lodash, run the following command to install its type definitions:
+
+```bash
+npm install --save-dev @types/lodash
+```
+
+If the npm package already includes its declaration typings in the package bundle, downloading the corresponding `@types` package is not needed. For more information, see the [TypeScript changelog blog post](https://github.blog/changelog/2020-12-16-npm-displays-packages-with-bundled-typescript-declarations/).
+
+## Importing other assets
+
+To use non-code assets with TypeScript, we need to defer the type for these imports. This requires a `custom.d.ts` file, which holds custom definitions for TypeScript in our project. Let's set up a declaration for `.svg` files:
+
+```ts displayName="custom.d.ts"
+declare module '*.svg' {
+  const content: any;
+  export default content;
+}
+```
+
+Here we declare a new module for SVGs by matching any import that ends in `.svg` and defining the module's `content` as `any`. We could be more explicit about it being a URL by defining the type as `string`. The same concept applies to other assets, including CSS, SCSS, JSON, and more.
+
+## Build performance
+
+> [!WARNING]
+> This may degrade build performance.
+
+See the [Build Performance](#TODO[/guides/build-performance/]) guide on build tooling.
diff --git a/pages/site.mjs b/pages/site.mjs
index 74f3a87a..605276a9 100644
--- a/pages/site.mjs
+++ b/pages/site.mjs
@@ -1,6 +1,7 @@
 import loaders from './docs/loaders/site.json' with { type: 'json' };
 import plugins from './docs/plugins/site.json' with { type: 'json' };
 import governance from './about/governance/site.json' with { type: 'json' };
+import guides from './guides/site.json' with { type: 'json' };
 import versions from '../versions.json' with { type: 'json' };
 import { major } from 'semver';
 
@@ -37,4 +38,5 @@ export const sidebar = {
     ...loaders.sidebar,
     ...plugins.sidebar,
   ],
+  guides: guides.sidebar,
 };

From 13624bf1b0a685f4e272cface6fec7fcfafc74b0 Mon Sep 17 00:00:00 2001
From: avivkeller <me@aviv.sh>
Date: Thu, 18 Jun 2026 20:19:37 -0600
Subject: [PATCH 2/2] fix some links

---
 .../guides/core-workflows/asset-management.md  | 12 ++++++------
 .../development/hot-module-replacement.md      |  8 ++++----
 .../guides/core-workflows/development/index.md | 10 +++++-----
 .../core-workflows/environment-variables.md    |  2 +-
 .../guides/core-workflows/output-management.md | 14 +++++++-------
 pages/guides/core-workflows/production.md      | 10 +++++-----
 .../concepts/dependency-graph.md               |  4 ++--
 .../getting-started/concepts/entry-points.md   |  2 +-
 .../concepts/hot-module-replacement.md         |  8 ++++----
 pages/guides/getting-started/concepts/index.md | 18 +++++++++---------
 .../guides/getting-started/concepts/loaders.md |  4 ++--
 .../getting-started/concepts/manifest.md       |  4 ++--
 .../concepts/module-resolution.md              |  2 +-
 .../guides/getting-started/concepts/modules.md |  4 ++--
 .../guides/getting-started/concepts/plugins.md |  2 +-
 .../guides/getting-started/concepts/targets.md |  2 +-
 .../getting-started/concepts/under-the-hood.md |  6 +++---
 .../getting-started/concepts/why-webpack.md    |  2 +-
 pages/guides/getting-started/index.md          | 16 ++++++++--------
 pages/guides/migration/to-v4.md                |  6 +++---
 pages/guides/migration/to-v5.md                |  6 +++---
 pages/guides/modern-web/index.md               |  8 ++++----
 .../modern-web/progressive-web-application.md  |  2 +-
 .../ecma-script-modules.md                     | 12 ++++++------
 .../modules-and-dependencies/entry-advanced.md |  2 +-
 .../modules-and-dependencies/shimming.md       | 10 +++++-----
 pages/guides/optimization/build-performance.md |  2 +-
 pages/guides/optimization/caching.md           |  6 +++---
 .../optimization/code-splitting/index.md       |  8 ++++----
 .../code-splitting/lazy-loading.md             |  6 +++---
 pages/guides/optimization/tree-shaking.md      |  6 +++---
 .../authoring-libraries.md                     |  4 ++--
 .../tooling-and-integration/integrations.md    |  2 +-
 .../tooling-and-integration/typescript.md      | 10 +++++-----
 34 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/pages/guides/core-workflows/asset-management.md b/pages/guides/core-workflows/asset-management.md
index 14f52c12..934afe3c 100644
--- a/pages/guides/core-workflows/asset-management.md
+++ b/pages/guides/core-workflows/asset-management.md
@@ -6,9 +6,9 @@ authors: skipjack,michael-ciniawsky,TheDutchCoder,sudarsangp,chenxsan,EugeneHlus
 
 If you've followed the guides from the beginning, you now have a small project that prints "Hello webpack". The next step is to bring in other kinds of assets, such as images, and see how webpack handles them.
 
-Before webpack, front-end developers relied on tools like [grunt](https://gruntjs.com/) and [gulp](https://gulpjs.com/) to process assets and copy them from a `/src` folder into a `/dist` or `/build` directory. JavaScript modules followed the same approach, but webpack takes it further: it **dynamically bundles** every dependency, building what's known as a [dependency graph](#TODO[/concepts/dependency-graph]). This is powerful because each module now _explicitly declares its dependencies_, which lets webpack skip anything that isn't actually used.
+Before webpack, front-end developers relied on tools like [grunt](https://gruntjs.com/) and [gulp](https://gulpjs.com/) to process assets and copy them from a `/src` folder into a `/dist` or `/build` directory. JavaScript modules followed the same approach, but webpack takes it further: it **dynamically bundles** every dependency, building what's known as a [dependency graph](/guides/getting-started/concepts/dependency-graph). This is powerful because each module now _explicitly declares its dependencies_, which lets webpack skip anything that isn't actually used.
 
-One of webpack's nicest features is that you can _import almost any type of file_, not just JavaScript, as long as there's a loader or built-in [Asset Modules](#TODO[/guides/asset-modules/]) support for it. That means the benefits you get with JavaScript, like explicit dependencies, apply to everything you use to build a site or web app. We'll begin with CSS, since that setup is probably already familiar to you.
+One of webpack's nicest features is that you can _import almost any type of file_, not just JavaScript, as long as there's a loader or built-in [Asset Modules](/guides/core-workflows/asset-modules) support for it. That means the benefits you get with JavaScript, like explicit dependencies, apply to everything you use to build a site or web app. We'll begin with CSS, since that setup is probably already familiar to you.
 
 ## Setup
 
@@ -48,7 +48,7 @@ First, make a small change to the project before we begin.
 
 ## Loading CSS
 
-To `import` a CSS file from within a JavaScript module, install the [style-loader](#TODO[/loaders/style-loader]) and [css-loader](#TODO[/loaders/css-loader]), then add them to your [`module` configuration](#TODO[/configuration/module]):
+To `import` a CSS file from within a JavaScript module, install the [style-loader](/docs/loaders/style-loader) and [css-loader](/docs/loaders/css-loader), then add them to your [`module` configuration](#TODO[/configuration/module]):
 
 ```bash
 npm install --save-dev style-loader css-loader
@@ -157,11 +157,11 @@ webpack 5.x.x compiled successfully in 2231 ms
 
 Open `dist/index.html` in your browser again and you should see `Hello webpack` styled in red. To check what webpack did, inspect the page rather than viewing the page source; the source won't reflect the result because the `<style>` tag is created dynamically by JavaScript. Look at the page's head tags, and you should find the style block we imported in `index.js`.
 
-Note that you can, and usually should, [minimize CSS](#TODO[/plugins/mini-css-extract-plugin/#minimizing-for-production]) for faster load times in production. On top of that, loaders exist for just about every flavor of CSS you can think of, including [postcss](#TODO[/loaders/postcss-loader]), [sass](#TODO[/loaders/sass-loader]), and [less](#TODO[/loaders/less-loader]).
+Note that you can, and usually should, [minimize CSS](/docs/plugins/mini-css-extract-plugin/#minimizing-for-production) for faster load times in production. On top of that, loaders exist for just about every flavor of CSS you can think of, including [postcss](/docs/loaders/postcss-loader), [sass](/docs/loaders/sass-loader), and [less](/docs/loaders/less-loader).
 
 ## Loading Images
 
-Now that CSS is in place, what about images such as backgrounds and icons? Since webpack 5, the built-in [Asset Modules](#TODO[/guides/asset-modules/]) make it easy to handle these as well:
+Now that CSS is in place, what about images such as backgrounds and icons? Since webpack 5, the built-in [Asset Modules](/guides/core-workflows/asset-modules) make it easy to handle these as well:
 
 ```diff displayName="webpack.config.js"
  import path from 'node:path';
@@ -191,7 +191,7 @@ Now that CSS is in place, what about images such as backgrounds and icons? Since
  };
 ```
 
-Now, when you write `import MyImage from './my-image.png'`, the image is processed and added to your `output` directory, and the `MyImage` variable holds its final URL after processing. When you use the [css-loader](#TODO[/loaders/css-loader]) as shown above, the same thing happens for `url('./my-image.png')` inside your CSS: the loader recognizes the local file and replaces the `'./my-image.png'` path with the final path to the image in your `output` directory. The [html-loader](#TODO[/loaders/html-loader]) handles `<img src="./my-image.png" />` the same way.
+Now, when you write `import MyImage from './my-image.png'`, the image is processed and added to your `output` directory, and the `MyImage` variable holds its final URL after processing. When you use the [css-loader](/docs/loaders/css-loader) as shown above, the same thing happens for `url('./my-image.png')` inside your CSS: the loader recognizes the local file and replaces the `'./my-image.png'` path with the final path to the image in your `output` directory. The [html-loader](/docs/loaders/html-loader) handles `<img src="./my-image.png" />` the same way.
 
 Let's add an image to the project to see this in action. You can use any image you like.
 
diff --git a/pages/guides/core-workflows/development/hot-module-replacement.md b/pages/guides/core-workflows/development/hot-module-replacement.md
index 9b1053e2..cd2d6284 100644
--- a/pages/guides/core-workflows/development/hot-module-replacement.md
+++ b/pages/guides/core-workflows/development/hot-module-replacement.md
@@ -5,12 +5,12 @@ authors: jmreidy,jhnns,sararubin,rohannair,joshsantos,drpicox,skipjack,sbaidon,g
 # Hot Module Replacement
 
 > [!TIP]
-> This guide builds on the code examples found in the [Development](#TODO[/guides/development]) guide.
+> This guide builds on the code examples found in the [Development](/guides/core-workflows/development) guide.
 
-Hot Module Replacement (HMR) is one of the most useful features webpack offers. It lets all kinds of modules update at runtime without a full page refresh. This page focuses on **implementation**, while the [concepts page](#TODO[/concepts/hot-module-replacement]) covers how HMR works and why it's useful.
+Hot Module Replacement (HMR) is one of the most useful features webpack offers. It lets all kinds of modules update at runtime without a full page refresh. This page focuses on **implementation**, while the [concepts page](/guides/getting-started/concepts/hot-module-replacement) covers how HMR works and why it's useful.
 
 > [!WARNING]
-> HMR is not intended for use in production; it should only be used during development. See the [building for production guide](#TODO[/guides/production]) for more information.
+> HMR is not intended for use in production; it should only be used during development. See the [building for production guide](/guides/core-workflows/production) for more information.
 
 ## Enabling HMR
 
@@ -206,7 +206,7 @@ try {
 See the [full documentation of the `webpack-dev-server` Node.js API](#TODO[/api/webpack-dev-server/]).
 
 > [!TIP]
-> If you're [using `webpack-dev-middleware`](#TODO[/guides/development/#using-webpack-dev-middleware]), check out the [`webpack-hot-middleware`](https://github.com/webpack/webpack-hot-middleware) package to enable HMR on your custom dev server.
+> If you're [using `webpack-dev-middleware`](/guides/core-workflows/development/#using-webpack-dev-middleware), check out the [`webpack-hot-middleware`](https://github.com/webpack/webpack-hot-middleware) package to enable HMR on your custom dev server.
 
 ## Gotchas
 
diff --git a/pages/guides/core-workflows/development/index.md b/pages/guides/core-workflows/development/index.md
index 9f266ba8..fcc3908d 100644
--- a/pages/guides/core-workflows/development/index.md
+++ b/pages/guides/core-workflows/development/index.md
@@ -5,7 +5,7 @@ authors: SpaceK33z,rafde,fvgs,TheDutchCoder,WojciechKo,Calinou,GAumala,EugeneHlu
 # Development
 
 > [!TIP]
-> This guide builds on the code examples from the [Output Management](#TODO[/guides/output-management]) guide.
+> This guide builds on the code examples from the [Output Management](/guides/core-workflows/output-management) guide.
 
 If you've worked through the previous guides, you should now have a solid grasp of webpack's fundamentals. Before moving on, let's set up a development environment that makes day-to-day work a little smoother.
 
@@ -222,7 +222,7 @@ Update your configuration file to tell the dev server where to find files:
 This tells `webpack-dev-server` to serve the files from the `dist` directory on `localhost:8080`.
 
 > [!TIP]
-> `optimization.runtimeChunk: 'single'` was added because this example uses more than one entry point on a single HTML page. Without it, we'd run into the problem described [here](https://bundlers.tooling.report/code-splitting/multi-entry/). See the [Code Splitting](#TODO[/guides/code-splitting/]) chapter for more details.
+> `optimization.runtimeChunk: 'single'` was added because this example uses more than one entry point on a single HTML page. Without it, we'd run into the problem described [here](https://bundlers.tooling.report/code-splitting/multi-entry/). See the [Code Splitting](/guides/optimization/code-splitting) chapter for more details.
 
 > [!TIP]
 > `webpack-dev-server` serves bundled files from the directory defined in [`output.path`](#TODO[/configuration/output/#outputpath]); that is, files are available under `http://[devServer.host]:[devServer.port]/[output.publicPath]/[output.filename]`.
@@ -264,7 +264,7 @@ Now run `npm start` from the command line, and your browser will open the page a
 `webpack-dev-server` offers many configurable options. Head over to the [documentation](#TODO[/configuration/dev-server]) to learn more.
 
 > [!TIP]
-> Now that your server is up and running, you might want to give [Hot Module Replacement](#TODO[/guides/hot-module-replacement]) a try!
+> Now that your server is up and running, you might want to give [Hot Module Replacement](/guides/core-workflows/development/hot-module-replacement) a try!
 
 ### Using webpack-dev-middleware
 
@@ -405,7 +405,7 @@ Example app listening on port 3000!
 Now open your browser at `http://localhost:3000`. You should see your webpack app up and running!
 
 > [!TIP]
-> If you'd like to learn more about how Hot Module Replacement works, we recommend reading the [Hot Module Replacement](#TODO[/guides/hot-module-replacement/]) guide.
+> If you'd like to learn more about how Hot Module Replacement works, we recommend reading the [Hot Module Replacement](/guides/core-workflows/development/hot-module-replacement) guide.
 
 ## Adjusting your text editor
 
@@ -419,4 +419,4 @@ To disable it in a few common editors:
 
 ## Conclusion
 
-Now that you know how to compile your code automatically and run a development server, you can move on to the next guide, which covers [Code Splitting](#TODO[/guides/code-splitting/]).
+Now that you know how to compile your code automatically and run a development server, you can move on to the next guide, which covers [Code Splitting](/guides/optimization/code-splitting).
diff --git a/pages/guides/core-workflows/environment-variables.md b/pages/guides/core-workflows/environment-variables.md
index e9c94a6a..f02b0b32 100644
--- a/pages/guides/core-workflows/environment-variables.md
+++ b/pages/guides/core-workflows/environment-variables.md
@@ -4,7 +4,7 @@ authors: simon04,grisanu,tbroadley,legalcodes,byzyk,jceipek,snitin315,Brennvo,av
 
 # Environment Variables
 
-To distinguish between [development](#TODO[/guides/development]) and [production builds](#TODO[/guides/production]) in your `webpack.config.js`, you can use environment variables.
+To distinguish between [development](/guides/core-workflows/development) and [production builds](/guides/core-workflows/production) in your `webpack.config.js`, you can use environment variables.
 
 > [!TIP]
 > webpack's environment variables are different from the [environment variables](https://en.wikipedia.org/wiki/Environment_variable) of operating system shells such as `bash` and `CMD.exe`.
diff --git a/pages/guides/core-workflows/output-management.md b/pages/guides/core-workflows/output-management.md
index 0cf4ca03..55789ca6 100644
--- a/pages/guides/core-workflows/output-management.md
+++ b/pages/guides/core-workflows/output-management.md
@@ -5,9 +5,9 @@ authors: skipjack,TheDutchCoder,sudarsangp,JGJP,EugeneHlushko,AnayaDesign,chenxs
 # Output Management
 
 > [!TIP]
-> This guide builds on the code examples from the [Asset Management](#TODO[/guides/asset-management]) guide.
+> This guide builds on the code examples from the [Asset Management](/guides/core-workflows/asset-management) guide.
 
-So far we've manually listed every asset in our `index.html` file. As an application grows, and once you start [using hashes in filenames](#TODO[/guides/caching]) and outputting [multiple bundles](#TODO[/guides/code-splitting]), maintaining `index.html` by hand becomes difficult. Fortunately, a few plugins make this much easier to manage.
+So far we've manually listed every asset in our `index.html` file. As an application grows, and once you start [using hashes in filenames](/guides/optimization/caching) and outputting [multiple bundles](/guides/optimization/code-splitting), maintaining `index.html` by hand becomes difficult. Fortunately, a few plugins make this much easier to manage.
 
 ## Preparation
 
@@ -117,13 +117,13 @@ webpack generates `print.bundle.js` and `index.bundle.js`, both of which we refe
 But what if we renamed one of our entry points, or added a new one? The generated bundles would be renamed on the next build, yet `index.html` would still reference the old names. Let's fix that with [`HtmlWebpackPlugin`](#TODO[/plugins/html-webpack-plugin]).
 
 > [!TIP]
-> If you inspected `print.bundle.js`, you might have noticed that it does not contain the `printMe` function. Instead, it contains only an [IIFE](#TODO[/concepts/why-webpack/#iifes---immediately-invoked-function-expressions]) with no observable side effects.
+> If you inspected `print.bundle.js`, you might have noticed that it does not contain the `printMe` function. Instead, it contains only an [IIFE](/guides/getting-started/concepts/why-webpack/#iifes---immediately-invoked-function-expressions) with no observable side effects.
 >
-> This is because, in our current setup, webpack treats each entry point as a standalone program that runs when the bundle is loaded. Since `print.js` only exports a function and never calls `printMe()`, running it as its own entry requires no executable runtime code. As a result, [webpack can omit that code as an optimization](#TODO[/guides/tree-shaking/]) because it would have no observable effect.
+> This is because, in our current setup, webpack treats each entry point as a standalone program that runs when the bundle is loaded. Since `print.js` only exports a function and never calls `printMe()`, running it as its own entry requires no executable runtime code. As a result, [webpack can omit that code as an optimization](/guides/optimization/tree-shaking) because it would have no observable effect.
 >
 > By contrast, since `index.js` imports and uses `printMe`, webpack includes that function directly in `index.bundle.js`. Remember that webpack is a module _bundler_, so `index.bundle.js` contains all the code it needs to run rather than unresolved import statements.
 >
-> The multiple entry points here exist solely to demonstrate output management and `HtmlWebpackPlugin`. In a real project, you'd typically avoid creating a separate entry point for a utility module like this. If you do have multiple entry points that share dependencies, see [Prevent Duplication](#TODO[/guides/code-splitting/#prevent-duplication]) in the Code Splitting guide.
+> The multiple entry points here exist solely to demonstrate output management and `HtmlWebpackPlugin`. In a real project, you'd typically avoid creating a separate entry point for a utility module like this. If you do have multiple entry points that share dependencies, see [Prevent Duplication](/guides/optimization/code-splitting/#prevent-duplication) in the Code Splitting guide.
 
 ## Setting up `HtmlWebpackPlugin`
 
@@ -218,8 +218,8 @@ You might wonder how webpack and its plugins seem to "know" which files are bein
 
 The manifest data can be extracted into a JSON file for consumption using the [`ManifestPlugin`](#TODO[/plugins/manifest-plugin/]).
 
-We won't walk through a full example of using this plugin in your project, but you can read the [concept page](#TODO[/concepts/manifest]) and the [caching guide](#TODO[/guides/caching]) to learn how this ties into long-term caching.
+We won't walk through a full example of using this plugin in your project, but you can read the [concept page](/guides/getting-started/concepts/manifest) and the [caching guide](/guides/optimization/caching) to learn how this ties into long-term caching.
 
 ## Conclusion
 
-Now that you've learned how to add bundles to your HTML dynamically, dive into the [development guide](#TODO[/guides/development]). Or, if you want to explore more advanced topics, head over to the [code splitting guide](#TODO[/guides/code-splitting]).
+Now that you've learned how to add bundles to your HTML dynamically, dive into the [development guide](/guides/core-workflows/development). Or, if you want to explore more advanced topics, head over to the [code splitting guide](/guides/optimization/code-splitting).
diff --git a/pages/guides/core-workflows/production.md b/pages/guides/core-workflows/production.md
index bacdebe8..9b8ee182 100644
--- a/pages/guides/core-workflows/production.md
+++ b/pages/guides/core-workflows/production.md
@@ -7,7 +7,7 @@ authors: henriquea,rajagopal4890,makuzaverite,markerikson,simon04,kisnows,chrisV
 In this guide, we'll explore some of the best practices and utilities for building a production site or application.
 
 > [!TIP]
-> This walkthrough builds on [Tree Shaking](#TODO[/guides/tree-shaking]) and [Development](#TODO[/guides/development]). Make sure you're familiar with the concepts and setup from those guides before continuing.
+> This walkthrough builds on [Tree Shaking](/guides/optimization/tree-shaking) and [Development](/guides/core-workflows/development). Make sure you're familiar with the concepts and setup from those guides before continuing.
 
 ## Setup
 
@@ -83,7 +83,7 @@ npm install --save-dev webpack-merge
 + });
 ```
 
-In `webpack.common.js`, we now have our `entry` and `output` configuration along with any plugins required by both environments. In `webpack.dev.js`, we've set `mode` to `development`, added the recommended `devtool` for that environment (strong source mapping), and configured our `devServer`. Finally, in `webpack.prod.js`, `mode` is set to `production`, which loads the [`MinimizerPlugin`](#TODO[/plugins/minimizer-webpack-plugin/]) first introduced in the [tree shaking](#TODO[/guides/tree-shaking/]) guide.
+In `webpack.common.js`, we now have our `entry` and `output` configuration along with any plugins required by both environments. In `webpack.dev.js`, we've set `mode` to `development`, added the recommended `devtool` for that environment (strong source mapping), and configured our `devServer`. Finally, in `webpack.prod.js`, `mode` is set to `production`, which loads the [`MinimizerPlugin`](/docs/plugins/minimizer-webpack-plugin) first introduced in the [tree shaking](/guides/optimization/tree-shaking) guide.
 
 Note the `merge()` calls in the environment-specific configurations, which pull in our common configuration in both `webpack.dev.js` and `webpack.prod.js`. `webpack-merge` offers a variety of advanced merging features, but we won't need any of them for this use case.
 
@@ -167,11 +167,11 @@ If you use a library like [`react`](https://reactjs.org/), you should see a sign
 
 webpack v4+ minifies your code by default in [production mode](#TODO[/configuration/mode/#mode-production]).
 
-While the [`MinimizerPlugin`](#TODO[/plugins/minimizer-webpack-plugin/]) is a great starting point and is used by default, other options exist:
+While the [`MinimizerPlugin`](/docs/plugins/minimizer-webpack-plugin) is a great starting point and is used by default, other options exist:
 
 - [`ClosureWebpackPlugin`](https://github.com/webpack-contrib/closure-webpack-plugin)
 
-If you decide to try another minification plugin, make sure your choice also drops dead code as described in the [tree shaking](#TODO[/guides/tree-shaking]) guide, and provide it via [`optimization.minimizer`](#TODO[/configuration/optimization/#optimizationminimizer]).
+If you decide to try another minification plugin, make sure your choice also drops dead code as described in the [tree shaking](/guides/optimization/tree-shaking) guide, and provide it via [`optimization.minimizer`](#TODO[/configuration/optimization/#optimizationminimizer]).
 
 ## Source mapping
 
@@ -192,7 +192,7 @@ We encourage you to enable source maps in production, as they're useful for debu
 
 ## Minimize CSS
 
-It's crucial to minimize your CSS for production. See the [Minimizing for Production](#TODO[/plugins/mini-css-extract-plugin/#minimizing-for-production]) section.
+It's crucial to minimize your CSS for production. See the [Minimizing for Production](/docs/plugins/mini-css-extract-plugin/#minimizing-for-production) section.
 
 ## CLI alternatives
 
diff --git a/pages/guides/getting-started/concepts/dependency-graph.md b/pages/guides/getting-started/concepts/dependency-graph.md
index 77d184fb..1cfd6d7c 100644
--- a/pages/guides/getting-started/concepts/dependency-graph.md
+++ b/pages/guides/getting-started/concepts/dependency-graph.md
@@ -6,10 +6,10 @@ authors: TheLarkInn,EugeneHlushko,avivkeller
 
 Whenever one file depends on another, webpack treats that relationship as a _dependency_. This lets webpack handle non-code assets, such as images and web fonts, by exposing them as dependencies of your application too.
 
-When webpack processes your application, it begins with a list of modules defined on the command line or in its configuration file. Starting from these [_entry points_](#TODO[/concepts/entry-points/]), webpack recursively builds a _dependency graph_ that contains every module your application needs. It then bundles all of those modules into a small number of _bundles_ — often just one — for the browser to load.
+When webpack processes your application, it begins with a list of modules defined on the command line or in its configuration file. Starting from these [_entry points_](/guides/getting-started/concepts/entry-points), webpack recursively builds a _dependency graph_ that contains every module your application needs. It then bundles all of those modules into a small number of _bundles_ — often just one — for the browser to load.
 
 > [!TIP]
-> Bundling is especially powerful for _HTTP/1.1_ clients, because it reduces how often the app has to wait for the browser to open a new request. For _HTTP/2_, you can additionally apply [Code Splitting](#TODO[/guides/code-splitting/]) for the best results.
+> Bundling is especially powerful for _HTTP/1.1_ clients, because it reduces how often the app has to wait for the browser to open a new request. For _HTTP/2_, you can additionally apply [Code Splitting](/guides/optimization/code-splitting) for the best results.
 
 ## Further reading
 
diff --git a/pages/guides/getting-started/concepts/entry-points.md b/pages/guides/getting-started/concepts/entry-points.md
index 47b37154..db94573d 100644
--- a/pages/guides/getting-started/concepts/entry-points.md
+++ b/pages/guides/getting-started/concepts/entry-points.md
@@ -4,7 +4,7 @@ authors: TheLarkInn,chrisVillanueva,byzyk,sokra,EugeneHlushko,Zearin,chenxsan,ad
 
 # Entry Points
 
-As mentioned in [Getting Started](#TODO[/guides/getting-started/#using-a-configuration]), there are several ways to define the `entry` property in your webpack configuration. This page walks through the ways you can configure `entry` and explains why each may be useful.
+As mentioned in [Getting Started](/guides/getting-started/#using-a-configuration), there are several ways to define the `entry` property in your webpack configuration. This page walks through the ways you can configure `entry` and explains why each may be useful.
 
 In simple terms, an entry point tells webpack where to start building its internal dependency graph. Starting from this file, webpack recursively follows every imported module and asset to determine what belongs in the final bundle.
 
diff --git a/pages/guides/getting-started/concepts/hot-module-replacement.md b/pages/guides/getting-started/concepts/hot-module-replacement.md
index 9c7e939a..ca3be5c6 100644
--- a/pages/guides/getting-started/concepts/hot-module-replacement.md
+++ b/pages/guides/getting-started/concepts/hot-module-replacement.md
@@ -4,7 +4,7 @@ authors: kryptokinght,SpaceK33z,sokra,GRardB,rouzbeh84,skipjack,avivkeller
 
 # Hot Module Replacement
 
-Hot Module Replacement (HMR) exchanges, adds, or removes [modules](#TODO[/concepts/modules/]) while an application is running, without a full reload. It can significantly speed up development in several ways:
+Hot Module Replacement (HMR) exchanges, adds, or removes [modules](/guides/getting-started/concepts/modules) while an application is running, without a full reload. It can significantly speed up development in several ways:
 
 - It preserves application state that would otherwise be lost during a full reload.
 - It saves valuable development time by updating only what changed.
@@ -29,7 +29,7 @@ You can configure HMR so that this process happens automatically, or you can req
 
 Beyond the usual assets, the compiler emits an "update" that allows moving from the previous version to the new one. An update has two parts:
 
-1. The updated [manifest](#TODO[/concepts/manifest]) (JSON).
+1. The updated [manifest](/guides/getting-started/concepts/manifest) (JSON).
 2. One or more updated chunks (JavaScript).
 
 The manifest contains the new compilation hash and a list of all updated chunks. Each chunk contains the new code for its updated modules, or a flag indicating that a module was removed.
@@ -46,7 +46,7 @@ See the [HMR API page](#TODO[/api/hot-module-replacement]) for details on the `m
 
 ### In the runtime
 
-Here things get a bit more technical. If you're not interested in the internals, feel free to skip ahead to the [HMR API page](#TODO[/api/hot-module-replacement]) or the [HMR guide](#TODO[/guides/hot-module-replacement]).
+Here things get a bit more technical. If you're not interested in the internals, feel free to skip ahead to the [HMR API page](#TODO[/api/hot-module-replacement]) or the [HMR guide](/guides/core-workflows/development/hot-module-replacement).
 
 For the module system runtime, additional code is emitted to track each module's `parents` and `children`. On the management side, the runtime supports two methods: `check` and `apply`.
 
@@ -58,7 +58,7 @@ Afterward, all invalid modules are disposed (via their dispose handlers) and unl
 
 ## Get started
 
-HMR can be used in development as a replacement for LiveReload. [webpack-dev-server](#TODO[/configuration/dev-server/]) supports a `hot` mode in which it tries to update with HMR before falling back to reloading the whole page. See the [Hot Module Replacement guide](#TODO[/guides/hot-module-replacement]) for details.
+HMR can be used in development as a replacement for LiveReload. [webpack-dev-server](#TODO[/configuration/dev-server/]) supports a `hot` mode in which it tries to update with HMR before falling back to reloading the whole page. See the [Hot Module Replacement guide](/guides/core-workflows/development/hot-module-replacement) for details.
 
 > [!TIP]
 > As with many other features, webpack's power lies in its customizability. There are _many_ ways to configure HMR depending on a project's needs. For most purposes, though, `webpack-dev-server` is a good fit and will get you started with HMR quickly.
diff --git a/pages/guides/getting-started/concepts/index.md b/pages/guides/getting-started/concepts/index.md
index b740ac78..16d1bff3 100644
--- a/pages/guides/getting-started/concepts/index.md
+++ b/pages/guides/getting-started/concepts/index.md
@@ -4,10 +4,10 @@ authors: TheLarkInn,jhnns,grgur,johnstew,jimrfenner,TheDutchCoder,adambraimbridg
 
 # Concepts
 
-At its core, **webpack** is a _static module bundler_ for modern JavaScript applications. When webpack processes your application, it internally builds a [dependency graph](#TODO[/concepts/dependency-graph/]) from one or more _entry points_ and then combines every module your project needs into one or more _bundles_, which are static assets that serve your content.
+At its core, **webpack** is a _static module bundler_ for modern JavaScript applications. When webpack processes your application, it internally builds a [dependency graph](/guides/getting-started/concepts/dependency-graph) from one or more _entry points_ and then combines every module your project needs into one or more _bundles_, which are static assets that serve your content.
 
 > [!TIP]
-> Learn more about JavaScript modules and webpack modules [here](#TODO[/concepts/modules]).
+> Learn more about JavaScript modules and webpack modules [here](/guides/getting-started/concepts/modules).
 
 Since version 4.0.0, **webpack does not require a configuration file** to bundle your project. Even so, it is [incredibly configurable](#TODO[/configuration]) to better fit your needs.
 
@@ -30,7 +30,7 @@ For a deeper understanding of the ideas behind module bundlers and how they work
 
 ## Entry
 
-An **entry point** tells webpack which module to use to begin building its internal [dependency graph](#TODO[/concepts/dependency-graph/]). From there, webpack determines which other modules and libraries that entry point depends on, both directly and indirectly.
+An **entry point** tells webpack which module to use to begin building its internal [dependency graph](/guides/getting-started/concepts/dependency-graph). From there, webpack determines which other modules and libraries that entry point depends on, both directly and indirectly.
 
 By default the entry is `./src/index.js`, but you can specify a different entry point — or multiple — by setting the [`entry` property in the webpack configuration](#TODO[/configuration/entry-context/#entry]). For example:
 
@@ -48,7 +48,7 @@ export default {
 > The error mentions `'./src'` rather than `'./src/index.js'` because webpack resolves the directory first and then fails to find the default `index.js` inside it. To use a different entry filename, add a `webpack.config.js` as shown in the example above.
 
 > [!TIP]
-> Learn more in the [entry points](#TODO[/concepts/entry-points]) section.
+> Learn more in the [entry points](/guides/getting-started/concepts/entry-points) section.
 
 ## Output
 
@@ -74,11 +74,11 @@ export default {
 In the example above, the `output.filename` and `output.path` properties tell webpack the name of our bundle and where to emit it. If you're wondering about the `path` module imported at the top, it is a core [Node.js module](https://nodejs.org/api/modules.html) used to manipulate file paths.
 
 > [!TIP]
-> The `output` property has [many more configurable features](#TODO[/configuration/output]). To learn about the concepts behind it, [read more in the output section](#TODO[/concepts/output]).
+> The `output` property has [many more configurable features](#TODO[/configuration/output]). To learn about the concepts behind it, [read more in the output section](/guides/getting-started/concepts/output).
 
 ## Loaders
 
-Out of the box, webpack only understands JavaScript and JSON files. **Loaders** let webpack process other types of files and convert them into valid [modules](#TODO[/concepts/modules]) that your application can consume and that can be added to the dependency graph.
+Out of the box, webpack only understands JavaScript and JSON files. **Loaders** let webpack process other types of files and convert them into valid [modules](/guides/getting-started/concepts/modules) that your application can consume and that can be added to the dependency graph.
 
 > [!WARNING]
 > One of webpack's distinctive features is the ability to `import` any type of module, for example `.css` files, which other bundlers or task runners may not support. We feel this extension of the language is warranted, because it lets developers build a more accurate dependency graph.
@@ -111,7 +111,7 @@ The configuration above defines a `rules` property with a single rule that has t
 > [!WARNING]
 > Keep in mind that when you use a regular expression to match files, you must not quote it. For example, `/\.txt$/` is not the same as `'/\.txt$/'` or `"/\.txt$/"`. The former tells webpack to match any file ending in `.txt`, while the latter tells webpack to match a single file with the absolute path `'.txt'`, which is likely not your intention.
 
-You can learn more about including loaders in the [loaders section](#TODO[/concepts/loaders]).
+You can learn more about including loaders in the [loaders section](/guides/getting-started/concepts/loaders).
 
 ## Plugins
 
@@ -139,7 +139,7 @@ In the example above, the `html-webpack-plugin` generates an HTML file for your
 > [!TIP]
 > webpack provides many plugins out of the box. Check out the [list of plugins](#TODO[/plugins]).
 
-Using plugins in your webpack configuration is straightforward, but there are many use cases worth exploring further. [Learn more about them here](#TODO[/concepts/plugins]).
+Using plugins in your webpack configuration is straightforward, but there are many use cases worth exploring further. [Learn more about them here](/guides/getting-started/concepts/plugins).
 
 ## Mode
 
@@ -155,7 +155,7 @@ Learn more about the [mode configuration here](#TODO[/configuration/mode]) and w
 
 ## Browser Compatibility
 
-webpack supports all browsers that are [ES5-compliant](https://compat-table.github.io/compat-table/es5/); IE8 and below are not supported. webpack needs `Promise` for [`import()` and `require.ensure()`](#TODO[/guides/code-splitting/#dynamic-imports]). To support older browsers, you will need to [load a polyfill](#TODO[/guides/shimming/]) before using these expressions.
+webpack supports all browsers that are [ES5-compliant](https://compat-table.github.io/compat-table/es5/); IE8 and below are not supported. webpack needs `Promise` for [`import()` and `require.ensure()`](/guides/optimization/code-splitting/#dynamic-imports). To support older browsers, you will need to [load a polyfill](/guides/modules-and-dependencies/shimming) before using these expressions.
 
 ## Environment
 
diff --git a/pages/guides/getting-started/concepts/loaders.md b/pages/guides/getting-started/concepts/loaders.md
index 8b9396d2..bb9a86e8 100644
--- a/pages/guides/getting-started/concepts/loaders.md
+++ b/pages/guides/getting-started/concepts/loaders.md
@@ -14,7 +14,7 @@ For instance, you can use loaders to tell webpack to load a CSS file or to conve
 npm install --save-dev css-loader ts-loader
 ```
 
-Then instruct webpack to use [`css-loader`](#TODO[/loaders/css-loader]) for every `.css` file and [`ts-loader`](https://github.com/TypeStrong/ts-loader) for every `.ts` file:
+Then instruct webpack to use [`css-loader`](/docs/loaders/css-loader) for every `.css` file and [`ts-loader`](https://github.com/TypeStrong/ts-loader) for every `.ts` file:
 
 ```js displayName="webpack.config.js"
 export default {
@@ -117,6 +117,6 @@ Loaders let you customize the output through their preprocessing functions. This
 
 ## Resolving loaders
 
-Loaders follow the standard [module resolution](#TODO[/concepts/module-resolution/]). In most cases they are loaded from the [module path](#TODO[/concepts/module-resolution/#module-paths]) (think `npm install` and `node_modules`).
+Loaders follow the standard [module resolution](/guides/getting-started/concepts/module-resolution). In most cases they are loaded from the [module path](/guides/getting-started/concepts/module-resolution/#module-paths) (think `npm install` and `node_modules`).
 
 A loader module is expected to export a function and be written in Node.js-compatible JavaScript. Loaders are most commonly managed with npm, but you can also keep custom loaders as files within your application. By convention, loaders are usually named `xxx-loader` (for example, `json-loader`). See [Writing a Loader](#TODO[/contribute/writing-a-loader/]) for more information.
diff --git a/pages/guides/getting-started/concepts/manifest.md b/pages/guides/getting-started/concepts/manifest.md
index 35a43bfe..f72254a6 100644
--- a/pages/guides/getting-started/concepts/manifest.md
+++ b/pages/guides/getting-started/concepts/manifest.md
@@ -28,10 +28,10 @@ So now you have a little insight into how webpack works behind the scenes. "But
 
 By using content hashes in your bundle file names, you can signal to the browser when a file's content has changed, which invalidates the cache. Once you start doing this, though, you'll immediately notice some odd behavior: certain hashes change even when their content apparently does not. This is caused by the injection of the runtime and manifest, which changes with every build.
 
-See [the manifest section](#TODO[/guides/output-management/#the-manifest]) of our _Output management_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long-term caching.
+See [the manifest section](/guides/core-workflows/output-management/#the-manifest) of our _Output management_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long-term caching.
 
 ## Further reading
 
 - [Separating a Manifest](https://survivejs.com/webpack/optimizing/separating-manifest/)
 - [Predictable Long Term Caching with webpack](https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31)
-- [Caching](#TODO[/guides/caching/])
+- [Caching](/guides/optimization/caching)
diff --git a/pages/guides/getting-started/concepts/module-resolution.md b/pages/guides/getting-started/concepts/module-resolution.md
index f80335a7..d1b0c553 100644
--- a/pages/guides/getting-started/concepts/module-resolution.md
+++ b/pages/guides/getting-started/concepts/module-resolution.md
@@ -48,7 +48,7 @@ import 'my-module/lib/file';
 
 Modules are searched for in every directory listed in [`resolve.modules`](#TODO[/configuration/resolve/#resolvemodules]). You can substitute a different path for the original module path by defining an alias through the [`resolve.alias`](#TODO[/configuration/resolve/#resolvealias]) configuration option.
 
-- If the package contains a `package.json` file, the fields listed in the [`resolve.exportsFields`](#TODO[/configuration/resolve/#resolveexportsfields]) configuration option are checked in order. The first matching field in `package.json` determines the package's available exports, following the [package exports guideline](#TODO[/guides/package-exports/]).
+- If the package contains a `package.json` file, the fields listed in the [`resolve.exportsFields`](#TODO[/configuration/resolve/#resolveexportsfields]) configuration option are checked in order. The first matching field in `package.json` determines the package's available exports, following the [package exports guideline](/guides/modules-and-dependencies/package-exports).
 
 Once the path is resolved by the rules above, the resolver checks whether it points to a file or a directory. If it points to a file:
 
diff --git a/pages/guides/getting-started/concepts/modules.md b/pages/guides/getting-started/concepts/modules.md
index c4df3b22..4c4daee4 100644
--- a/pages/guides/getting-started/concepts/modules.md
+++ b/pages/guides/getting-started/concepts/modules.md
@@ -24,10 +24,10 @@ Unlike [Node.js modules](https://nodejs.org/api/modules.html), webpack modules c
 
 webpack supports the following module types natively:
 
-- [ECMAScript modules](#TODO[/guides/ecma-script-modules])
+- [ECMAScript modules](/guides/modules-and-dependencies/ecma-script-modules)
 - CommonJS modules
 - AMD modules
-- [Assets](#TODO[/guides/asset-modules])
+- [Assets](/guides/core-workflows/asset-modules)
 - WebAssembly modules
 
 Beyond these, webpack supports modules written in many other languages and preprocessors through _loaders_. Loaders tell webpack **how** to process non-native modules and how to include their dependencies in your bundles. The webpack community has built loaders for a wide range of popular languages and language processors, including:
diff --git a/pages/guides/getting-started/concepts/plugins.md b/pages/guides/getting-started/concepts/plugins.md
index 653121bf..0375cea2 100644
--- a/pages/guides/getting-started/concepts/plugins.md
+++ b/pages/guides/getting-started/concepts/plugins.md
@@ -6,7 +6,7 @@ authors: TheLarkInn,jhnns,rouzbeh84,johnstew,MisterDev,byzyk,chenxsan,avivkeller
 
 Plugins are the [backbone](https://github.com/webpack/tapable) of webpack. webpack itself is built on the **same plugin system** that you use in your own configuration.
 
-Plugins also handle **anything else** that a [loader](#TODO[/concepts/loaders]) cannot do. webpack ships with [many plugins](#TODO[/plugins/]) out of the box.
+Plugins also handle **anything else** that a [loader](/guides/getting-started/concepts/loaders) cannot do. webpack ships with [many plugins](#TODO[/plugins/]) out of the box.
 
 > [!TIP]
 > When consuming the [`webpack-sources`](https://github.com/webpack/webpack-sources) package in plugins, prefer `compiler.webpack.sources` over importing from `webpack` or `webpack-sources` directly. This avoids version conflicts with persistent caching.
diff --git a/pages/guides/getting-started/concepts/targets.md b/pages/guides/getting-started/concepts/targets.md
index 153a4bde..07ad871b 100644
--- a/pages/guides/getting-started/concepts/targets.md
+++ b/pages/guides/getting-started/concepts/targets.md
@@ -7,7 +7,7 @@ authors: TheLarkInn,rouzbeh84,johnstew,srilman,byzyk,EugeneHlushko,avivkeller
 Because JavaScript can run on both the server and the browser, webpack offers several deployment _targets_ that you can set in your webpack [configuration](#TODO[/configuration]).
 
 > [!WARNING]
-> Do not confuse the webpack `target` property with the `output.libraryTarget` property. For more information, see our [guide](#TODO[/concepts/output/]) on the `output` property.
+> Do not confuse the webpack `target` property with the `output.libraryTarget` property. For more information, see our [guide](/guides/getting-started/concepts/output) on the `output` property.
 
 ## Usage
 
diff --git a/pages/guides/getting-started/concepts/under-the-hood.md b/pages/guides/getting-started/concepts/under-the-hood.md
index d490ffaa..fcd32e73 100644
--- a/pages/guides/getting-started/concepts/under-the-hood.md
+++ b/pages/guides/getting-started/concepts/under-the-hood.md
@@ -9,11 +9,11 @@ authors: smelukov,EugeneHlushko,chenxsan,amirsaeed671,avivkeller
 
 At its core, bundling is a function that takes some files and emits others.
 
-Between input and output, however, it works with [modules](#TODO[/concepts/modules/]), [entry points](#TODO[/concepts/entry-points/]), chunks, chunk groups, and many other intermediate pieces.
+Between input and output, however, it works with [modules](/guides/getting-started/concepts/modules), [entry points](/guides/getting-started/concepts/entry-points), chunks, chunk groups, and many other intermediate pieces.
 
 ## The main parts
 
-Every file used in your project is a [module](#TODO[/concepts/modules/]).
+Every file used in your project is a [module](/guides/getting-started/concepts/modules).
 
 ```js displayName="./index.js"
 import app from './app.js';
@@ -56,7 +56,7 @@ This creates two chunk groups, named `home` and `about`. Each has one chunk cont
 Chunks come in two forms:
 
 - `initial` is the main chunk for an entry point. It contains all the modules and their dependencies that you specify for that entry point.
-- `non-initial` is a chunk that may be lazy-loaded. It can appear when a [dynamic import](#TODO[/guides/code-splitting/#dynamic-imports]) or [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is used.
+- `non-initial` is a chunk that may be lazy-loaded. It can appear when a [dynamic import](/guides/optimization/code-splitting/#dynamic-imports) or [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is used.
 
 Each chunk has a corresponding **asset**. Assets are the output files, the result of bundling.
 
diff --git a/pages/guides/getting-started/concepts/why-webpack.md b/pages/guides/getting-started/concepts/why-webpack.md
index ff5ff6ba..dd420857 100644
--- a/pages/guides/getting-started/concepts/why-webpack.md
+++ b/pages/guides/getting-started/concepts/why-webpack.md
@@ -36,7 +36,7 @@ The good news for web projects is that modules are becoming an official feature
 
 ## Automatic dependency collection
 
-Old-school task runners, and even the Google Closure Compiler, require you to declare all dependencies manually and upfront. Bundlers like webpack, by contrast, automatically build and infer your [dependency graph](#TODO[/concepts/dependency-graph/]) from what you import and export. Together with [plugins](#TODO[/concepts/plugins/]) and [loaders](#TODO[/concepts/loaders/]), this makes for a great developer experience.
+Old-school task runners, and even the Google Closure Compiler, require you to declare all dependencies manually and upfront. Bundlers like webpack, by contrast, automatically build and infer your [dependency graph](/guides/getting-started/concepts/dependency-graph) from what you import and export. Together with [plugins](/guides/getting-started/concepts/plugins) and [loaders](/guides/getting-started/concepts/loaders), this makes for a great developer experience.
 
 ## Wouldn't it be nice…
 
diff --git a/pages/guides/getting-started/index.md b/pages/guides/getting-started/index.md
index ba44b747..e636b866 100644
--- a/pages/guides/getting-started/index.md
+++ b/pages/guides/getting-started/index.md
@@ -6,7 +6,7 @@ authors: bebraw,varunjayaraman,cntanglijun,chrisVillanueva,johnstew,simon04,aaro
 
 webpack is a good fit when your application needs a customizable build pipeline: bundling JavaScript modules, processing assets, integrating loaders and plugins, and shaping output for different environments. For a very small page with one or two scripts, a bundler may be unnecessary at first; but for an application with shared dependencies, npm packages, assets, and production builds, webpack gives you explicit control over how everything is assembled.
 
-webpack is used to efficiently compile JavaScript modules. Once [installed](#TODO[/guides/installation]), you can interact with webpack through either its [CLI](#TODO[/api/cli]) or its [API](#TODO[/api/node]). If you're new to webpack, please read through the [core concepts](#TODO[/concepts]) and [this comparison](#TODO[/comparison]) to learn why you might choose it over the other tools available in the community.
+webpack is used to efficiently compile JavaScript modules. Once [installed](/guides/getting-started/installing-webpack), you can interact with webpack through either its [CLI](#TODO[/api/cli]) or its [API](#TODO[/api/node]). If you're new to webpack, please read through the [core concepts](/guides/getting-started/concepts) and [this comparison](#TODO[/comparison]) to learn why you might choose it over the other tools available in the community.
 
 > [!WARNING]
 > The examples in this guide use `webpack-cli` 7, which requires Node.js 20.9.0 or later.
@@ -30,7 +30,7 @@ cd webpack-demo
 
 ## Basic setup
 
-First, let's create a directory, initialize npm, [install webpack locally](#TODO[/guides/installation/#local-installation]), and install the [`webpack-cli`](https://github.com/webpack/webpack-cli) (the tool used to run webpack on the command line):
+First, let's create a directory, initialize npm, [install webpack locally](/guides/getting-started/installing-webpack/#local-installation), and install the [`webpack-cli`](https://github.com/webpack/webpack-cli) (the tool used to run webpack on the command line):
 
 ```bash
 # Run the commands for one package manager only.
@@ -150,7 +150,7 @@ First, we'll tweak our directory structure slightly, separating the "source" cod
        └── index.js
 ```
 
-The `dist` directory is build output, so in a mature project you usually do not hand-edit files there. We are moving `index.html` into `dist` for now only as temporary scaffolding, so the browser has an HTML file that loads the first generated bundle. Later, in [another guide](#TODO[/guides/output-management/#setting-up-htmlwebpackplugin]), we'll generate `index.html` rather than edit it manually. Once that's done, it should be safe to empty the `dist` directory and regenerate all the files within it.
+The `dist` directory is build output, so in a mature project you usually do not hand-edit files there. We are moving `index.html` into `dist` for now only as temporary scaffolding, so the browser has an HTML file that loads the first generated bundle. Later, in [another guide](/guides/core-workflows/output-management/#setting-up-htmlwebpackplugin), we'll generate `index.html` rather than edit it manually. Once that's done, it should be safe to empty the `dist` directory and regenerate all the files within it.
 
 To bundle the `lodash` dependency with `index.js`, we'll need to install the library locally:
 
@@ -210,7 +210,7 @@ In this setup, `index.js` explicitly requires `lodash` to be present and binds i
 > [!TIP]
 > A couple of other script-loading strategies exist. Deferred loading is one alternative to the above: scripts are consolidated into the `<head>` and given the `defer` attribute. This strategy downloads external script resources in parallel with document parsing and executes the scripts in order of document appearance after parsing has finished. This contrasts with the approach above, in which the parser pauses to download and then execute the external resource synchronously. To learn more, MDN has a nice [reference guide](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script#async_and_defer).
 
-With that said, let's run `npx webpack` from the project root. If webpack is installed locally, `npx` runs the local binary from `node_modules/.bin`; otherwise, it may download and execute it. This command takes our script at `src/index.js` as the [entry point](#TODO[/concepts/entry-points]) and generates `dist/main.js` as the [output](#TODO[/concepts/output]).
+With that said, let's run `npx webpack` from the project root. If webpack is installed locally, `npx` runs the local binary from `node_modules/.bin`; otherwise, it may download and execute it. This command takes our script at `src/index.js` as the [entry point](/guides/getting-started/concepts/entry-points) and generates `dist/main.js` as the [output](/guides/getting-started/concepts/output).
 
 ```bash
 # Run the command for one package manager only.
@@ -247,11 +247,11 @@ The [`import`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference
 
 Behind the scenes, webpack analyzes your module graph and bundles the modules into code the browser can load in the right order. It handles module syntax such as `import` and `export`, and supports various other module syntaxes as well. See [Module API](#TODO[/api/module-methods]) for more information.
 
-Note that webpack will not alter any code other than `import` and `export` statements. If you're using other [ES2015 features](http://es6-features.org/), make sure to [use a transpiler](#TODO[/loaders/#transpiling]) such as [Babel](https://babeljs.io/) via webpack's [loader system](#TODO[/concepts/loaders/]).
+Note that webpack will not alter any code other than `import` and `export` statements. If you're using other [ES2015 features](http://es6-features.org/), make sure to [use a transpiler](#TODO[/loaders/#transpiling]) such as [Babel](https://babeljs.io/) via webpack's [loader system](/guides/getting-started/concepts/loaders).
 
 ## Using a configuration
 
-As of version 4, webpack doesn't require any configuration, but most projects will need a more complex setup, which is why webpack supports a [configuration file](#TODO[/concepts/configuration]). This is much more efficient than manually typing a lot of commands in the terminal, so let's create one.
+As of version 4, webpack doesn't require any configuration, but most projects will need a more complex setup, which is why webpack supports a [configuration file](/guides/getting-started/concepts/configuration). This is much more efficient than manually typing a lot of commands in the terminal, so let's create one.
 
 webpack configuration files can be written using either CommonJS or ECMAScript modules. The examples below use modern ESM syntax.
 
@@ -372,7 +372,7 @@ webpack 5.x.x compiled successfully in 1940 ms
 
 ## Conclusion
 
-Now that you have a basic build together, you should move on to the next guide, [Asset Management](#TODO[/guides/asset-management]), to learn how to manage assets such as images and fonts with webpack. At this point, your project should look like this:
+Now that you have a basic build together, you should move on to the next guide, [Asset Management](/guides/core-workflows/asset-management), to learn how to manage assets such as images and fonts with webpack. At this point, your project should look like this:
 
 ```diff displayName="project"
 webpack-demo
@@ -390,4 +390,4 @@ webpack-demo
 > [!WARNING]
 > Do not compile untrusted code with webpack. It could lead to execution of malicious code on your computer, on remote servers, or in the web browsers of your application's end users.
 
-If you want to learn more about webpack's design, you can check out the [basic concepts](#TODO[/concepts]) and [configuration](#TODO[/configuration]) pages. Furthermore, the [API](#TODO[/api]) section digs into the various interfaces webpack offers.
+If you want to learn more about webpack's design, you can check out the [basic concepts](/guides/getting-started/concepts) and [configuration](#TODO[/configuration]) pages. Furthermore, the [API](#TODO[/api]) section digs into the various interfaces webpack offers.
diff --git a/pages/guides/migration/to-v4.md b/pages/guides/migration/to-v4.md
index 8bb126b0..0d640ef9 100644
--- a/pages/guides/migration/to-v4.md
+++ b/pages/guides/migration/to-v4.md
@@ -14,9 +14,9 @@ You can find instructions for upgrading Node.js [here](https://stackoverflow.com
 
 ## CLI
 
-The CLI has moved into its own package, `webpack-cli`. You must install it before using webpack; see [basic setup](#TODO[/guides/getting-started/#basic-setup]).
+The CLI has moved into its own package, `webpack-cli`. You must install it before using webpack; see [basic setup](/guides/getting-started/#basic-setup).
 
-The installation guide is available [here](#TODO[/guides/installation]).
+The installation guide is available [here](/guides/getting-started/installing-webpack).
 
 ## Update plugins
 
@@ -34,7 +34,7 @@ module.exports = {
 ```
 
 > [!TIP]
-> `'development'` mode and `'production'` mode serve different purposes. You can use `webpack-merge`, as shown in the [production guide](#TODO[/guides/production/#setup]), to maintain separate optimized configurations.
+> `'development'` mode and `'production'` mode serve different purposes. You can use `webpack-merge`, as shown in the [production guide](/guides/core-workflows/production/#setup), to maintain separate optimized configurations.
 
 ## Deprecated and removed plugins
 
diff --git a/pages/guides/migration/to-v5.md b/pages/guides/migration/to-v5.md
index e5f40ea8..6bf29e24 100644
--- a/pages/guides/migration/to-v5.md
+++ b/pages/guides/migration/to-v5.md
@@ -14,7 +14,7 @@ webpack 5 requires at least Node.js 10.13.0 (LTS), so upgrade your Node.js insta
 
 1. Upgrade `webpack` 4 to the latest available version.
    - If you are already on webpack >= 4, upgrading to the latest webpack 4 release should not require additional guidance.
-   - If you are on a version earlier than 4, follow the [webpack 4 migration guide](#TODO[/migrate/4/]) first.
+   - If you are on a version earlier than 4, follow the [webpack 4 migration guide](/guides/migration/to-v4) first.
 
 2. Upgrade `webpack-cli` to the latest available version (if you use it).
 
@@ -78,7 +78,7 @@ Update the following options to their new form (if you use them):
 - `Rule.loaders` → [`Rule.use`](#TODO[/configuration/module/#ruleuse])
 
 > [!TIP]
-> Review the detailed configuration changes [here](#TODO[/blog/2020-10-10-webpack-5-release/#changes-to-the-configuration]).
+> Review the detailed configuration changes [here](/blog/posts/2020-10-10-webpack-5-release/#changes-to-the-configuration).
 
 ### Test webpack 5 compatibility
 
@@ -117,7 +117,7 @@ If you were unable to upgrade some plugins or loaders to their latest versions i
 - If you use `IgnorePlugin` with a regular expression argument, it now takes an `options` object: `new IgnorePlugin({ resourceRegExp: /regExp/ })`.
 - If you use something like `node.fs: 'empty'`, replace it with `resolve.fallback.fs: false`.
 - If you use `watch: true` in the webpack Node.js API, remove it. It is unnecessary, since the compiler method you call already indicates watch mode: `watch()` for watching and `run()` for a single build.
-- If you have `rules` that load assets with `raw-loader`, `url-loader`, or `file-loader`, use [Asset Modules](#TODO[/guides/asset-modules/]) instead, as those loaders will be deprecated soon.
+- If you have `rules` that load assets with `raw-loader`, `url-loader`, or `file-loader`, use [Asset Modules](/guides/core-workflows/asset-modules) instead, as those loaders will be deprecated soon.
 - If you have `target` set to a function, set it to `false` and apply that function in the `plugins` option instead. For example:
 
   ```json
diff --git a/pages/guides/modern-web/index.md b/pages/guides/modern-web/index.md
index 542a46f1..1418dd40 100644
--- a/pages/guides/modern-web/index.md
+++ b/pages/guides/modern-web/index.md
@@ -7,7 +7,7 @@ authors: phoekerson,avivkeller
 This guide describes practical webpack patterns for **Web Components**, **Import Maps**, and **Progressive Web Apps** (PWAs) with **Service Workers**. Each section states the problem, shows a minimal configuration you can copy, and notes the current limits relative to future webpack improvements.
 
 > [!TIP]
-> Familiarity with [code splitting](#TODO[/guides/code-splitting/]), [caching](#TODO[/guides/caching/]) (`[contenthash]`), and the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is helpful here.
+> Familiarity with [code splitting](/guides/optimization/code-splitting), [caching](/guides/optimization/caching) (`[contenthash]`), and the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) is helpful here.
 
 ## Web Components with webpack
 
@@ -17,7 +17,7 @@ If more than one JavaScript bundle calls `customElements.define()` for the same
 
 ### Approach
 
-Use [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) so the module that defines the element lives in a **single shared chunk** that loads once. Adjust `cacheGroups` so your element definitions (or a dedicated folder such as `src/elements/`) are forced into one chunk. See [Prevent Duplication](#TODO[/guides/code-splitting/#prevent-duplication]) for the general idea.
+Use [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) so the module that defines the element lives in a **single shared chunk** that loads once. Adjust `cacheGroups` so your element definitions (or a dedicated folder such as `src/elements/`) are forced into one chunk. See [Prevent Duplication](/guides/optimization/code-splitting/#prevent-duplication) for the general idea.
 
 ```js displayName="webpack.config.js"
 import path from 'node:path';
@@ -135,9 +135,9 @@ webpack **does not** emit or update `importmap.json` for you. You must maintain
 
 ### Problem
 
-Long-lived caching requires **stable URLs** for HTML but **versioned URLs** for scripts and styles. Using [`[contenthash]`](#TODO[/guides/caching/]) in `output.filename` changes those URLs every build. A **service worker** precache list must list the **exact** URLs after each build, or offline shells will point at missing files.
+Long-lived caching requires **stable URLs** for HTML but **versioned URLs** for scripts and styles. Using [`[contenthash]`](/guides/optimization/caching) in `output.filename` changes those URLs every build. A **service worker** precache list must list the **exact** URLs after each build, or offline shells will point at missing files.
 
-The [`workbox-webpack-plugin`](#TODO[/guides/progressive-web-application/]) **`GenerateSW`** plugin generates an entire service worker for you. That is convenient, but when you need **full control** over the service worker code (custom routing, `skipWaiting` behavior, or coordination with `[contenthash]` and other plugins), **`InjectManifest`** is appropriate: you write the worker, and Workbox injects the precache manifest at build time from webpack's asset list.
+The [`workbox-webpack-plugin`](/guides/modern-web/progressive-web-application) **`GenerateSW`** plugin generates an entire service worker for you. That is convenient, but when you need **full control** over the service worker code (custom routing, `skipWaiting` behavior, or coordination with `[contenthash]` and other plugins), **`InjectManifest`** is appropriate: you write the worker, and Workbox injects the precache manifest at build time from webpack's asset list.
 
 ### Approach
 
diff --git a/pages/guides/modern-web/progressive-web-application.md b/pages/guides/modern-web/progressive-web-application.md
index 6a2656dd..45202efb 100644
--- a/pages/guides/modern-web/progressive-web-application.md
+++ b/pages/guides/modern-web/progressive-web-application.md
@@ -5,7 +5,7 @@ authors: johnnyreilly,chenxsan,EugeneHlushko,benschac,aholzner,avivkeller
 # Progressive Web Application
 
 > [!TIP]
-> This guide builds on the code examples from the [Output Management](#TODO[/guides/output-management]) guide.
+> This guide builds on the code examples from the [Output Management](/guides/core-workflows/output-management) guide.
 
 Progressive Web Applications (PWAs) are web apps that deliver an experience similar to native applications. Many things can contribute to this, but the most significant is an app's ability to function while **offline**. This is achieved with a web technology called [Service Workers](https://developers.google.com/web/fundamentals/primers/service-workers/).
 
diff --git a/pages/guides/modules-and-dependencies/ecma-script-modules.md b/pages/guides/modules-and-dependencies/ecma-script-modules.md
index f199dc37..dba9c358 100644
--- a/pages/guides/modules-and-dependencies/ecma-script-modules.md
+++ b/pages/guides/modules-and-dependencies/ecma-script-modules.md
@@ -79,12 +79,12 @@ Beyond the module format itself, flagging modules as ESM also affects the resolv
 
 webpack exposes several `import.meta` properties for use in ESM:
 
-| Property                     | Description                                                                                            |
-| ---------------------------- | ------------------------------------------------------------------------------------------------------ |
-| `import.meta.url`            | The URL of the current module file — use it for `new Worker()` or `new URL()`.                         |
-| `import.meta.webpack`        | The webpack major version number (e.g. `5`).                                                           |
-| `import.meta.webpackHot`     | Equivalent of `module.hot` — use it for HMR in ESM.                                                    |
-| `import.meta.webpackContext` | [ESM equivalent of `require.context`](#TODO[/guides/dependency-management/#importmetawebpackcontext]). |
+| Property                     | Description                                                                                                              |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
+| `import.meta.url`            | The URL of the current module file — use it for `new Worker()` or `new URL()`.                                           |
+| `import.meta.webpack`        | The webpack major version number (e.g. `5`).                                                                             |
+| `import.meta.webpackHot`     | Equivalent of `module.hot` — use it for HMR in ESM.                                                                      |
+| `import.meta.webpackContext` | [ESM equivalent of `require.context`](/guides/modules-and-dependencies/dependency-management/#importmetawebpackcontext). |
 
 **Example — using `import.meta.url` for assets:**
 
diff --git a/pages/guides/modules-and-dependencies/entry-advanced.md b/pages/guides/modules-and-dependencies/entry-advanced.md
index 30117a59..fe96622a 100644
--- a/pages/guides/modules-and-dependencies/entry-advanced.md
+++ b/pages/guides/modules-and-dependencies/entry-advanced.md
@@ -26,7 +26,7 @@ console.log('account page type');
 // account page individual styles
 ```
 
-As a best practice, we'll use [`MiniCssExtractPlugin`](#TODO[/plugins/mini-css-extract-plugin/]) in `production` mode for the CSS.
+As a best practice, we'll use [`MiniCssExtractPlugin`](/docs/plugins/mini-css-extract-plugin) in `production` mode for the CSS.
 
 ```js displayName="webpack.config.js"
 import MiniCssExtractPlugin from 'mini-css-extract-plugin';
diff --git a/pages/guides/modules-and-dependencies/shimming.md b/pages/guides/modules-and-dependencies/shimming.md
index f3703cb6..8152d783 100644
--- a/pages/guides/modules-and-dependencies/shimming.md
+++ b/pages/guides/modules-and-dependencies/shimming.md
@@ -14,7 +14,7 @@ Another case where shimming is useful is when you want to [polyfill](https://en.
 The following article walks through both of these use cases.
 
 > [!TIP]
-> For simplicity, this guide builds on the examples from [Getting Started](#TODO[/guides/getting-started]). Make sure you're familiar with that setup before moving on.
+> For simplicity, this guide builds on the examples from [Getting Started](/guides/getting-started). Make sure you're familiar with that setup before moving on.
 
 ## Shimming globals
 
@@ -131,7 +131,7 @@ We can also use `ProvidePlugin` to expose a single export of a module by configu
  };
 ```
 
-This pairs nicely with [Tree Shaking](#TODO[/guides/tree-shaking]), as the rest of the `lodash` library should get dropped.
+This pairs nicely with [Tree Shaking](/guides/optimization/tree-shaking), as the rest of the `lodash` library should get dropped.
 
 ## Granular shimming
 
@@ -152,7 +152,7 @@ Some legacy modules rely on `this` being the `window` object. Let's update our `
  document.body.appendChild(component());
 ```
 
-This becomes a problem when the module runs in a CommonJS context, where `this` equals `module.exports`. In that case, you can override `this` using the [`imports-loader`](#TODO[/loaders/imports-loader/]):
+This becomes a problem when the module runs in a CommonJS context, where `this` equals `module.exports`. In that case, you can override `this` using the [`imports-loader`](/docs/loaders/imports-loader):
 
 ```diff displayName="webpack.config.js"
  import path from "node:path";
@@ -212,7 +212,7 @@ const helpers = {
 };
 ```
 
-You'd likely never write code like this in your own source, but you may come across a dated library that contains something similar. In that case, we can use [`exports-loader`](#TODO[/loaders/exports-loader/]) to export that global variable as a normal module export. For instance, to export `file` as `file` and `helpers.parse` as `parse`:
+You'd likely never write code like this in your own source, but you may come across a dated library that contains something similar. In that case, we can use [`exports-loader`](/docs/loaders/exports-loader) to export that global variable as a normal module export. For instance, to export `file` as `file` and `helpers.parse` as `parse`:
 
 ```diff displayName="webpack.config.js"
  import path from "node:path";
@@ -453,7 +453,7 @@ When a module has no AMD or CommonJS version and you want to include its `dist`,
 > [!WARNING]
 > Any feature requiring the AST, such as `ProvidePlugin`, will not work.
 
-Finally, some modules support multiple [module styles](#TODO[/concepts/modules]) (for example, a combination of AMD, CommonJS, and legacy). In most of these cases, they first check for `define` and then use some quirky code to export properties. In these cases, it can help to force the CommonJS path by setting `additionalCode=var%20define%20=%20false;` via the [`imports-loader`](#TODO[/loaders/imports-loader/]).
+Finally, some modules support multiple [module styles](/guides/getting-started/concepts/modules) (for example, a combination of AMD, CommonJS, and legacy). In most of these cases, they first check for `define` and then use some quirky code to export properties. In these cases, it can help to force the CommonJS path by setting `additionalCode=var%20define%20=%20false;` via the [`imports-loader`](/docs/loaders/imports-loader).
 
 ## Further reading
 
diff --git a/pages/guides/optimization/build-performance.md b/pages/guides/optimization/build-performance.md
index e6a771c3..4c0cb935 100644
--- a/pages/guides/optimization/build-performance.md
+++ b/pages/guides/optimization/build-performance.md
@@ -8,7 +8,7 @@ This guide collects practical tips for improving the speed of your builds and co
 
 ## General
 
-The advice below applies whether you're running build scripts in [development](#TODO[/guides/development]) or [production](#TODO[/guides/production]).
+The advice below applies whether you're running build scripts in [development](/guides/core-workflows/development) or [production](/guides/core-workflows/production).
 
 ### Stay up to date
 
diff --git a/pages/guides/optimization/caching.md b/pages/guides/optimization/caching.md
index 28133f99..9107cd05 100644
--- a/pages/guides/optimization/caching.md
+++ b/pages/guides/optimization/caching.md
@@ -5,7 +5,7 @@ authors: okonet,jouni-kantola,skipjack,dannycjones,fadysamirsadek,afontcu,rosava
 # Caching
 
 > [!TIP]
-> The examples in this guide build on [getting started](#TODO[/guides/getting-started]), [output management](#TODO[/guides/output-management]), and [code splitting](#TODO[/guides/code-splitting]).
+> The examples in this guide build on [getting started](/guides/getting-started), [output management](/guides/core-workflows/output-management), and [code splitting](/guides/optimization/code-splitting).
 
 We use webpack to bundle a modular application into a deployable `/dist` directory. Once that directory is deployed to a server, clients (usually browsers) request the site and its assets from that server. Downloading those assets can be slow, so browsers rely on a technique called [caching](<https://en.wikipedia.org/wiki/Cache_(computing)>) to load sites faster and avoid unnecessary network traffic. The downside is that caching can get in the way when you actually want clients to pick up new code.
 
@@ -15,7 +15,7 @@ This guide covers the configuration you need so that files produced by a webpack
 
 The `output.filename` [substitutions](#TODO[/configuration/output/#outputfilename]) setting lets us define the names of our output files. webpack supports templating filenames with bracketed strings called **substitutions**. The `[contenthash]` substitution adds a unique hash derived from an asset's content, so whenever that content changes the hash changes too.
 
-Let's set up the project using the example from [getting started](#TODO[/guides/getting-started]), along with the `plugins` from [output management](#TODO[/guides/output-management]), so we don't have to maintain `index.html` by hand:
+Let's set up the project using the example from [getting started](/guides/getting-started), along with the `plugins` from [output management](/guides/core-workflows/output-management), so we don't have to maintain `index.html` by hand:
 
 ```diff displayName="project"
 webpack-demo
@@ -80,7 +80,7 @@ This happens because webpack includes certain boilerplate, specifically the runt
 
 ## Extracting boilerplate
 
-As we saw in [code splitting](#TODO[/guides/code-splitting]), the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) can split modules out into separate bundles. webpack also offers an optimization that splits the runtime code into its own chunk via the [`optimization.runtimeChunk`](#TODO[/configuration/optimization/#optimizationruntimechunk]) option. Set it to `single` to create a single runtime bundle shared across all chunks:
+As we saw in [code splitting](/guides/optimization/code-splitting), the [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) can split modules out into separate bundles. webpack also offers an optimization that splits the runtime code into its own chunk via the [`optimization.runtimeChunk`](#TODO[/configuration/optimization/#optimizationruntimechunk]) option. Set it to `single` to create a single runtime bundle shared across all chunks:
 
 ```diff displayName="webpack.config.js"
  import path from 'node:path';
diff --git a/pages/guides/optimization/code-splitting/index.md b/pages/guides/optimization/code-splitting/index.md
index e719c921..1e4bc575 100644
--- a/pages/guides/optimization/code-splitting/index.md
+++ b/pages/guides/optimization/code-splitting/index.md
@@ -5,7 +5,7 @@ authors: pksjce,pastelsky,simon04,jonwheeler,johnstew,shinxi,tomtasche,levy9527,
 # Code Splitting
 
 > [!TIP]
-> This guide builds on the example from [Getting Started](#TODO[/guides/getting-started]). Make sure you are at least familiar with that example and the [Output Management](#TODO[/guides/output-management/]) chapter before continuing.
+> This guide builds on the example from [Getting Started](/guides/getting-started). Make sure you are at least familiar with that example and the [Output Management](/guides/core-workflows/output-management) chapter before continuing.
 
 Code splitting is one of webpack's most compelling features. It lets you split your code into multiple bundles that can be loaded on demand or in parallel. Used well, it produces smaller bundles and gives you control over resource load prioritization, which can have a significant impact on load time.
 
@@ -223,7 +223,7 @@ webpack 5.x.x compiled successfully in 241 ms
 
 Here are some other useful community plugins and loaders for splitting code:
 
-- [`mini-css-extract-plugin`](#TODO[/plugins/mini-css-extract-plugin]): Useful for splitting CSS out of the main application.
+- [`mini-css-extract-plugin`](/docs/plugins/mini-css-extract-plugin): Useful for splitting CSS out of the main application.
 
 ## Dynamic Imports
 
@@ -232,7 +232,7 @@ webpack supports two similar techniques for dynamic code splitting. The first an
 > [!WARNING]
 > `import()` calls use [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) internally. If you use `import()` with older browsers (such as IE 11), remember to shim `Promise` with a polyfill like [es6-promise](https://github.com/stefanpenner/es6-promise) or [promise-polyfill](https://github.com/taylorhakes/promise-polyfill).
 
-Before we begin, let's remove the extra [`entry`](#TODO[/concepts/entry-points/]) and [`optimization.splitChunks`](#TODO[/plugins/split-chunks-plugin]) configuration from the previous example, since they aren't needed for this demonstration:
+Before we begin, let's remove the extra [`entry`](/guides/getting-started/concepts/entry-points) and [`optimization.splitChunks`](#TODO[/plugins/split-chunks-plugin]) configuration from the previous example, since they aren't needed for this demonstration:
 
 ```diff displayName="webpack.config.js"
  import path from 'node:path';
@@ -452,7 +452,7 @@ Once you start splitting your code, it can be helpful to analyze the output to s
 
 ## Next Steps
 
-See [Lazy Loading](#TODO[/guides/lazy-loading/]) for a more concrete example of how `import()` can be used in a real application, and [Caching](#TODO[/guides/caching/]) to learn how to split code more effectively.
+See [Lazy Loading](/guides/optimization/code-splitting/lazy-loading) for a more concrete example of how `import()` can be used in a real application, and [Caching](/guides/optimization/caching) to learn how to split code more effectively.
 
 ## Further reading
 
diff --git a/pages/guides/optimization/code-splitting/lazy-loading.md b/pages/guides/optimization/code-splitting/lazy-loading.md
index 44b9a7f5..89cb29aa 100644
--- a/pages/guides/optimization/code-splitting/lazy-loading.md
+++ b/pages/guides/optimization/code-splitting/lazy-loading.md
@@ -5,15 +5,15 @@ authors: iammerrick,chrisVillanueva,skipjack,byzyk,EugeneHlushko,AnayaDesign,tap
 # Lazy Loading
 
 > [!TIP]
-> This guide is a short follow-up to [Code Splitting](#TODO[/guides/code-splitting]). If you haven't read through that guide yet, please do so now.
+> This guide is a short follow-up to [Code Splitting](/guides/optimization/code-splitting). If you haven't read through that guide yet, please do so now.
 
 Lazy, or "on demand", loading is a great way to optimize your site or application. The practice essentially involves splitting your code at logical breakpoints and then loading a block of code once the user does something that requires it (or will soon require it). This speeds up the initial load of the application and lightens its overall weight, since some blocks may never be loaded at all.
 
 ## Dynamic import example
 
-Let's take the example from [Code Splitting](#TODO[/guides/code-splitting/#dynamic-imports]) and tweak it to demonstrate this concept more clearly. The code there does cause a separate chunk, `lodash.bundle.js`, to be generated and technically "lazy-loads" it as soon as the script runs. The trouble is that no user interaction is required to load the bundle, which means the request fires every time the page loads. That doesn't help us much and negatively impacts performance.
+Let's take the example from [Code Splitting](/guides/optimization/code-splitting/#dynamic-imports) and tweak it to demonstrate this concept more clearly. The code there does cause a separate chunk, `lodash.bundle.js`, to be generated and technically "lazy-loads" it as soon as the script runs. The trouble is that no user interaction is required to load the bundle, which means the request fires every time the page loads. That doesn't help us much and negatively impacts performance.
 
-Let's try something different. We'll add an interaction that logs some text to the console when the user clicks a button. However, we'll wait to load that code (`print.js`) until the interaction occurs for the first time. To do this, we'll go back and rework the [final _Dynamic Imports_ example](#TODO[/guides/code-splitting/#dynamic-imports]) from _Code Splitting_, leaving `lodash` in the main chunk.
+Let's try something different. We'll add an interaction that logs some text to the console when the user clicks a button. However, we'll wait to load that code (`print.js`) until the interaction occurs for the first time. To do this, we'll go back and rework the [final _Dynamic Imports_ example](/guides/optimization/code-splitting/#dynamic-imports) from _Code Splitting_, leaving `lodash` in the main chunk.
 
 ```diff displayName="project"
 webpack-demo
diff --git a/pages/guides/optimization/tree-shaking.md b/pages/guides/optimization/tree-shaking.md
index 0b206cd7..8d295ac0 100644
--- a/pages/guides/optimization/tree-shaking.md
+++ b/pages/guides/optimization/tree-shaking.md
@@ -9,7 +9,7 @@ _Tree shaking_ is a term commonly used in JavaScript for dead-code elimination.
 webpack 2 introduced built-in support for ES2015 modules (also known as _harmony modules_) along with detection of unused module exports. webpack 4 expanded on this by letting you hint to the compiler, via the `"sideEffects"` property in `package.json`, which files in your project are "pure" and therefore safe to prune if unused.
 
 > [!TIP]
-> The rest of this guide builds on [Getting Started](#TODO[/guides/getting-started]). If you haven't read through that guide yet, please do so now.
+> The rest of this guide builds on [Getting Started](/guides/getting-started). If you haven't read through that guide yet, please do so now.
 
 ## Add a utility
 
@@ -227,7 +227,7 @@ const Button$1 = /* #__PURE__ */ withAppProvider()(Button);
 
 This allows the piece of code to be removed. But there are still questions about the imports, which need to be included and evaluated because they could contain side effects.
 
-To tackle this, we use the [`"sideEffects"`](#TODO[/guides/tree-shaking/#mark-the-file-as-side-effect-free]) property in `package.json`.
+To tackle this, we use the [`"sideEffects"`](/guides/optimization/tree-shaking/#mark-the-file-as-side-effect-free) property in `package.json`.
 
 It's similar to `/*#__PURE__*/`, but at the module level rather than the statement level. The `"sideEffects"` property says: "If no direct export from a module flagged as side-effect-free is used, the bundler can skip evaluating the module for side effects."
 
@@ -568,7 +568,7 @@ What we've learned is that, to take advantage of _tree shaking_, you must:
 
 You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves consumed by autumn. To get rid of the dead leaves, you have to shake the tree, causing them to fall.
 
-If you're interested in more ways to optimize your output, head to the next guide for details on building for [production](#TODO[/guides/production]).
+If you're interested in more ways to optimize your output, head to the next guide for details on building for [production](/guides/core-workflows/production).
 
 ## Further reading
 
diff --git a/pages/guides/tooling-and-integration/authoring-libraries.md b/pages/guides/tooling-and-integration/authoring-libraries.md
index c7eff7fd..47fd2af4 100644
--- a/pages/guides/tooling-and-integration/authoring-libraries.md
+++ b/pages/guides/tooling-and-integration/authoring-libraries.md
@@ -287,7 +287,7 @@ export default {
 
 ## Final steps
 
-Optimize your output for production by following the steps in the [production guide](#TODO[/guides/production]). Let's also point the package's `main` field in `package.json` at your generated bundle:
+Optimize your output for production by following the steps in the [production guide](/guides/core-workflows/production). Let's also point the package's `main` field in `package.json` at your generated bundle:
 
 ```json displayName="package.json"
 {
@@ -315,4 +315,4 @@ The `main` key refers to the [standard from `package.json`](https://docs.npmjs.c
 You can now [publish it as an npm package](https://docs.npmjs.com/getting-started/publishing-npm-packages) and find it on [unpkg.com](https://unpkg.com/#/) to distribute it to your users.
 
 > [!TIP]
-> To expose stylesheets associated with your library, use the [`MiniCssExtractPlugin`](#TODO[/plugins/mini-css-extract-plugin]). Users can then consume and load them as they would any other stylesheet.
+> To expose stylesheets associated with your library, use the [`MiniCssExtractPlugin`](/docs/plugins/mini-css-extract-plugin). Users can then consume and load them as they would any other stylesheet.
diff --git a/pages/guides/tooling-and-integration/integrations.md b/pages/guides/tooling-and-integration/integrations.md
index 61e4b7bf..14e50c85 100644
--- a/pages/guides/tooling-and-integration/integrations.md
+++ b/pages/guides/tooling-and-integration/integrations.md
@@ -6,7 +6,7 @@ authors: pksjce,bebraw,tashian,skipjack,AnayaDesign,avivkeller
 
 Let's start by clearing up a common misconception. webpack is a module bundler like [Browserify](http://browserify.org/) or [Brunch](https://brunch.io/). It is _not_ a task runner like [Make](https://www.gnu.org/software/make/), [Grunt](https://gruntjs.com/), or [Gulp](https://gulpjs.com/). Task runners automate common development tasks such as linting, building, or testing your project. Compared with bundlers, task runners operate at a higher level. You can still benefit from their higher-level tooling while leaving the problem of bundling to webpack.
 
-Bundlers help you prepare your JavaScript and stylesheets for deployment, transforming them into a format suitable for the browser. For example, JavaScript can be [minified](#TODO[/plugins/minimizer-webpack-plugin/]) or [split into chunks](#TODO[/guides/code-splitting]) and [lazy-loaded](#TODO[/guides/lazy-loading]) to improve performance. Bundling is one of the most important challenges in web development, and solving it well removes a great deal of pain from the process.
+Bundlers help you prepare your JavaScript and stylesheets for deployment, transforming them into a format suitable for the browser. For example, JavaScript can be [minified](/docs/plugins/minimizer-webpack-plugin) or [split into chunks](/guides/optimization/code-splitting) and [lazy-loaded](/guides/optimization/code-splitting/lazy-loading) to improve performance. Bundling is one of the most important challenges in web development, and solving it well removes a great deal of pain from the process.
 
 The good news is that, although there is some overlap, task runners and bundlers can work well together when approached the right way. This guide provides a high-level overview of how webpack can be integrated into some of the more popular task runners.
 
diff --git a/pages/guides/tooling-and-integration/typescript.md b/pages/guides/tooling-and-integration/typescript.md
index 9be1ec4c..76568d37 100644
--- a/pages/guides/tooling-and-integration/typescript.md
+++ b/pages/guides/tooling-and-integration/typescript.md
@@ -5,7 +5,7 @@ authors: morsdyce,kkamali,mtrivera,byzyk,EugeneHlushko,chenxsan,snitin315,tushar
 # TypeScript
 
 > [!TIP]
-> This guide builds on the [Getting Started](#TODO[/guides/getting-started/]) guide.
+> This guide builds on the [Getting Started](/guides/getting-started) guide.
 
 [TypeScript](https://www.typescriptlang.org) is a typed superset of JavaScript that compiles to plain JavaScript. In this guide, we'll learn how to integrate TypeScript with webpack.
 
@@ -53,7 +53,7 @@ Let's set up a configuration that supports JSX and compiles TypeScript down to E
 }
 ```
 
-See [TypeScript's documentation](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) to learn more about `tsconfig.json` configuration options. To learn more about webpack configuration, see the [configuration concepts](#TODO[/concepts/configuration/]).
+See [TypeScript's documentation](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) to learn more about `tsconfig.json` configuration options. To learn more about webpack configuration, see the [configuration concepts](/guides/getting-started/concepts/configuration).
 
 Now let's configure webpack to handle TypeScript. First, install the required dependencies:
 
@@ -246,13 +246,13 @@ npm uninstall tsconfig-paths-webpack-plugin
 We use `ts-loader` in this guide because it makes enabling additional webpack features, such as importing other web assets, a bit easier.
 
 > [!WARNING]
-> `ts-loader` uses `tsc`, the TypeScript compiler, and relies on your `tsconfig.json` configuration. Be sure to avoid setting [`module`](https://www.typescriptlang.org/tsconfig#module) to "CommonJS", or webpack won't be able to [tree-shake your code](#TODO[/guides/tree-shaking]).
+> `ts-loader` uses `tsc`, the TypeScript compiler, and relies on your `tsconfig.json` configuration. Be sure to avoid setting [`module`](https://www.typescriptlang.org/tsconfig#module) to "CommonJS", or webpack won't be able to [tree-shake your code](/guides/optimization/tree-shaking).
 
 Note that if you're already using [`babel-loader`](https://github.com/babel/babel-loader) to transpile your code, you can use [`@babel/preset-typescript`](https://babeljs.io/docs/en/babel-preset-typescript) and let Babel handle both your JavaScript and TypeScript files instead of using an additional loader. Keep in mind that, unlike `ts-loader`, the underlying [`@babel/plugin-transform-typescript`](https://babeljs.io/docs/en/babel-plugin-transform-typescript) plugin does not perform any type checking.
 
 ## Source maps
 
-To learn more about source maps, see the [development guide](#TODO[/guides/development]).
+To learn more about source maps, see the [development guide](/guides/core-workflows/development).
 
 To enable source maps, we must configure TypeScript to output inline source maps to our compiled JavaScript files. The following line must be added to our TypeScript configuration:
 
@@ -357,4 +357,4 @@ Here we declare a new module for SVGs by matching any import that ends in `.svg`
 > [!WARNING]
 > This may degrade build performance.
 
-See the [Build Performance](#TODO[/guides/build-performance/]) guide on build tooling.
+See the [Build Performance](/guides/optimization/build-performance) guide on build tooling.