fix(docs):resolve the guide TODOs for the plugin to its API references

pages/guides/getting-started/concepts/module-federation.md

@@ -49,7 +49,7 @@ This plugin adds specific references to containers as externals and allows impor
 
 ### `ModuleFederationPlugin` (high level)
 
-[`ModuleFederationPlugin`](#TODO[/plugins/module-federation-plugin]) combines `ContainerPlugin` and `ContainerReferencePlugin`.
+[`ModuleFederationPlugin`](/docs/api/v5.x/container/ModuleFederationPlugin) combines `ContainerPlugin` and `ContainerReferencePlugin`.
 
 ## Concept goals
 

pages/guides/getting-started/concepts/under-the-hood.md

@@ -49,14 +49,14 @@ export default {
 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.
+> A chunk group may contain more than one chunk. For example, [`SplitChunksPlugin`](/docs/api/v5.x/optimize/SplitChunksPlugin) 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](/guides/optimization/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`](/docs/api/v5.x/optimize/SplitChunksPlugin) is used.
 
 Each chunk has a corresponding **asset**. Assets are the output files, the result of bundling.
 

pages/guides/migration/to-v3.md

@@ -445,7 +445,7 @@ A welcome benefit: because loading is now Promise-based, you can handle the fail
 
 ## 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.
+You can pass a partial expression to `import()`. This works much like expressions in CommonJS: webpack creates a [context](/docs/api/v5.x/plugins/ContextReplacementPlugin) containing all possible files, and `import()` produces a separate chunk for each possible module.
 
 ```js
 function route(path, query) {
@@ -539,7 +539,7 @@ module.exports = {
 
 Several new CLI options are available:
 
-- `--define process.env.NODE_ENV="production"` — see [`DefinePlugin`](#TODO[/plugins/define-plugin/]).
+- `--define process.env.NODE_ENV="production"` — see [`DefinePlugin`](/docs/api/v5.x/plugins/DefinePlugin).
 - `--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).

pages/guides/migration/to-v5.md

@@ -331,7 +331,7 @@ The following changes to webpack internals (added types, refactored code, rename
 
 ### `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):
+webpack 5 ships with a built-in [`this.getOptions`](/docs/api/v5.x/loaders/types#interface-normalmoduleloadercontext) 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.

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](/guides/optimization/code-splitting), [caching](/guides/optimization/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`](/docs/api/v5.x/optimize/SplitChunksPlugin) is helpful here.
 
 ## Web Components with webpack
 

pages/guides/modules-and-dependencies/shimming.md

@@ -34,7 +34,7 @@ webpack-demo
 
 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:
+The [`ProvidePlugin`](/docs/api/v5.x/plugins/ProvidePlugin) 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';

pages/guides/optimization/caching.md

@@ -80,7 +80,7 @@ This happens because webpack includes certain boilerplate, specifically the runt
 
 ## Extracting boilerplate
 
-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:
+As we saw in [code splitting](/guides/optimization/code-splitting), the [`SplitChunksPlugin`](/docs/api/v5.x/optimize/SplitChunksPlugin) 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';
@@ -124,7 +124,7 @@ runtime.cc17ae2a94ec771e9221.js   1.42 KiB       0  [emitted]  runtime
     + 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:
+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`](/docs/api/v5.x/chunks/types#interface-optimizationsplitchunksoptions) option of the [`SplitChunksPlugin`](/docs/api/v5.x/optimize/SplitChunksPlugin). Let's add `optimization.splitChunks` with `cacheGroups` and the following parameters, then build:
 
 ```diff displayName="webpack.config.js"
  import path from 'node:path';

pages/guides/optimization/code-splitting/index.md

@@ -12,7 +12,7 @@ Code splitting is one of webpack's most compelling features. It lets you split y
 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.
+- **Prevent duplication**: Use [entry dependencies](#TODO[/configuration/entry-context/#dependencies]) or the [`SplitChunksPlugin`](/docs/api/v5.x/optimize/SplitChunksPlugin) to deduplicate and split chunks.
 - **Dynamic imports**: Split code through inline function calls within modules.
 
 ## Entry Points
@@ -174,7 +174,7 @@ Although webpack allows multiple entry points per page, you should avoid it when
 
 ### 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:
+The [`SplitChunksPlugin`](/docs/api/v5.x/optimize/SplitChunksPlugin) 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';
@@ -201,7 +201,7 @@ The [`SplitChunksPlugin`](#TODO[/plugins/split-chunks-plugin/]) lets you extract
   };
 ```
 
-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.
+With the [`optimization.splitChunks`](/docs/api/v5.x/chunks/types#interface-optimizationsplitchunksoptions) 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](/docs/api/v5.x/chunks/types#interface-optimizationsplitchunksoptions) specified by webpack.
 
 Run `npm run build` to confirm it worked:
 
@@ -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`](/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:
+Before we begin, let's remove the extra [`entry`](/guides/getting-started/concepts/entry-points) and [`optimization.splitChunks`](/docs/api/v5.x/chunks/types#interface-optimizationsplitchunksoptions) configuration from the previous example, since they aren't needed for this demonstration:
 
 ```diff displayName="webpack.config.js"
  import path from 'node:path';

pages/guides/optimization/tree-shaking.md

@@ -518,7 +518,7 @@ 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.
+> [`ModuleConcatenationPlugin`](/docs/api/v5.x/optimize/ModuleConcatenationPlugin) is required for tree shaking to work. It's added by `mode: 'production'`. If you're not using that mode, remember to add [`ModuleConcatenationPlugin`](/docs/api/v5.x/optimize/ModuleConcatenationPlugin) manually.
 
 ## Common pitfalls with side effects