From 97273011e875603563ba31857ec5638bdea658bb Mon Sep 17 00:00:00 2001 From: Nikhil Kumar Rajak Date: Wed, 15 Jul 2026 13:43:35 +0000 Subject: [PATCH] fix(guides): rewrite reference links --- .../guides/core-workflows/asset-management.md | 6 +++--- pages/guides/core-workflows/asset-modules.md | 14 ++++++------- .../core-workflows/development/index.md | 12 +++++------ .../core-workflows/output-management.md | 6 +++--- pages/guides/core-workflows/production.md | 10 +++++----- .../getting-started/concepts/configuration.md | 10 +++------- .../getting-started/concepts/entry-points.md | 8 ++++---- .../concepts/hot-module-replacement.md | 4 ++-- .../guides/getting-started/concepts/index.md | 8 ++++---- .../getting-started/concepts/loaders.md | 4 ++-- .../getting-started/concepts/manifest.md | 2 +- .../concepts/module-federation.md | 2 +- .../concepts/module-resolution.md | 20 +++++++++---------- .../guides/getting-started/concepts/output.md | 4 ++-- .../getting-started/concepts/targets.md | 6 +++--- .../concepts/under-the-hood.md | 6 +++--- pages/guides/getting-started/index.md | 6 +++--- pages/guides/migration/to-v3.md | 8 ++++---- pages/guides/migration/to-v4.md | 8 ++++---- pages/guides/migration/to-v5.md | 14 ++++++------- pages/guides/modern-web/index.md | 8 ++++---- pages/guides/modern-web/native-css.md | 2 +- .../modern-web/progressive-web-application.md | 2 +- .../ecma-script-modules.md | 4 ++-- .../entry-advanced.md | 2 +- .../package-exports.md | 14 ++++++------- .../modules-and-dependencies/shimming.md | 4 ++-- .../guides/optimization/build-performance.md | 2 +- pages/guides/optimization/caching.md | 6 +++--- .../optimization/code-splitting/index.md | 8 ++++---- .../code-splitting/lazy-loading.md | 2 +- pages/guides/optimization/tree-shaking.md | 14 ++++++------- .../authoring-libraries.md | 8 ++++---- .../content-security-policy.md | 2 +- .../tooling-and-integration/typescript.md | 7 ++----- 35 files changed, 118 insertions(+), 125 deletions(-) diff --git a/pages/guides/core-workflows/asset-management.md b/pages/guides/core-workflows/asset-management.md index 934afe3c..ae696e69 100644 --- a/pages/guides/core-workflows/asset-management.md +++ b/pages/guides/core-workflows/asset-management.md @@ -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](/docs/loaders/style-loader) and [css-loader](/docs/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](/docs/api/options#module): ```bash npm install --save-dev style-loader css-loader @@ -510,7 +510,7 @@ 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. +You can import `toml`, `yaml`, or `json5` files as JSON modules by supplying a [custom parser](/docs/api/options#modulerules) instead of a dedicated webpack loader. Suppose you have `data.toml`, `data.yaml`, and `data.json5` files in the `src` folder: @@ -680,7 +680,7 @@ The best part of everything described above is that loading assets this way lets 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`. +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](/docs/api/options#resolvealias) to make them easier to `import`. ## Wrapping up diff --git a/pages/guides/core-workflows/asset-modules.md b/pages/guides/core-workflows/asset-modules.md index 85dc55d5..a69393ba 100644 --- a/pages/guides/core-workflows/asset-modules.md +++ b/pages/guides/core-workflows/asset-modules.md @@ -124,13 +124,13 @@ 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. +All `.png` files will be emitted to the output directory and their paths will be injected into the bundles. You can also customize [`outputPath`](/docs/api/options#modulerules) and [`publicPath`](/docs/api/options#modulerules) 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: +You can change this template by setting [`output.assetModuleFilename`](/docs/api/options#outputassetmodulefilename) in your webpack configuration: ```diff displayName="webpack.config.js" import path from "node:path"; @@ -189,7 +189,7 @@ export default { 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. +`Rule.generator.filename` behaves the same as [`output.assetModuleFilename`](/docs/api/options#outputassetmodulefilename) and works only with the `asset` and `asset/resource` module types. ## Inlining assets @@ -325,7 +325,7 @@ When you use `new URL('./path/to/asset', import.meta.url)`, webpack creates an a 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: +Depending on the [`target`](/docs/api/options#target) in your configuration, webpack compiles the code above into different output: ```js // target: web @@ -386,7 +386,7 @@ export default { 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: +You can change this condition by setting the [`Rule.parser.dataUrlCondition.maxSize`](/docs/api/options#modulerules) option at the module rule level of your webpack configuration: ```diff displayName="webpack.config.js" import path from "node:path"; @@ -417,7 +417,7 @@ export default { }; ``` -You can also [specify a function](#TODO[/configuration/module/#ruleparserdataurlcondition]) to decide whether to inline a module. +You can also [specify a function](/docs/api/options#modulerules) to decide whether to inline a module. ## Bytes type @@ -542,7 +542,7 @@ module: { ## 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`: +For use cases such as server-side rendering, you might want to disable emitting assets. This is possible with the [`emit`](/docs/api/options#modulerules) option under `Rule.generator`: ```js export default { diff --git a/pages/guides/core-workflows/development/index.md b/pages/guides/core-workflows/development/index.md index fcc3908d..71a66671 100644 --- a/pages/guides/core-workflows/development/index.md +++ b/pages/guides/core-workflows/development/index.md @@ -12,7 +12,7 @@ If you've worked through the previous guides, you should now have a solid grasp > [!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'`. +Start by setting [`mode` to `'development'`](/docs/api/options#mode) and `title` to `'Development'`. ```diff displayName="webpack.config.js" import path from 'node:path'; @@ -48,7 +48,7 @@ When webpack bundles your source code, tracing errors and warnings back to their 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. +webpack offers many [different options](/docs/api/options#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: @@ -123,7 +123,7 @@ Manually running `npm run build` every time you want to compile quickly becomes webpack provides several options that recompile your code automatically whenever it changes: -1. webpack's [Watch Mode](#TODO[/configuration/watch/#watch]) +1. webpack's [Watch Mode](/docs/api/options#watch) 2. [webpack-dev-server](https://github.com/webpack/webpack-dev-server) 3. [webpack-dev-middleware](https://github.com/webpack/webpack-dev-middleware) @@ -225,10 +225,10 @@ This tells `webpack-dev-server` to serve the files from the `dist` directory on > `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]`. +> `webpack-dev-server` serves bundled files from the directory defined in [`output.path`](/docs/api/options#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. +> `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`](/docs/api/options#devserver) option in the dev server's configuration. Let's also add a script to make running the dev server easier: @@ -261,7 +261,7 @@ Let's also add a script to make running the dev server easier: 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. +`webpack-dev-server` offers many configurable options. Head over to the [documentation](/docs/api/options#devserver) to learn more. > [!TIP] > 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! diff --git a/pages/guides/core-workflows/output-management.md b/pages/guides/core-workflows/output-management.md index da8a357a..87bb0e8d 100644 --- a/pages/guides/core-workflows/output-management.md +++ b/pages/guides/core-workflows/output-management.md @@ -114,7 +114,7 @@ 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]). +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`](https://www.npmjs.com/package/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](/guides/getting-started/concepts/why-webpack/#iifes---immediately-invoked-function-expressions) with no observable side effects. @@ -182,7 +182,7 @@ To learn more about the features and options that `HtmlWebpackPlugin` provides, 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: +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`](/docs/api/options#outputclean) option takes care of this: ```diff displayName="webpack.config.js" import path from 'node:path'; @@ -214,7 +214,7 @@ Run `npm run build` again and inspect the `/dist` folder. If everything went wel ## 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. +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`](/docs/api/options#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`](/docs/api/plugins/ManifestPlugin). diff --git a/pages/guides/core-workflows/production.md b/pages/guides/core-workflows/production.md index 9b8ee182..03e981fa 100644 --- a/pages/guides/core-workflows/production.md +++ b/pages/guides/core-workflows/production.md @@ -126,7 +126,7 @@ Feel free to run these scripts and watch how the output changes as we continue b ## 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): +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`](/docs/api/options#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'; @@ -165,17 +165,17 @@ If you use a library like [`react`](https://reactjs.org/), you should see a sign ## Minification -webpack v4+ minifies your code by default in [production mode](#TODO[/configuration/mode/#mode-production]). +webpack v4+ minifies your code by default in [production mode](/docs/api/options#mode). 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](/guides/optimization/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`](/docs/api/options#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: +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`](/docs/api/options#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'; @@ -196,6 +196,6 @@ It's crucial to minimize your CSS for production. See the [Minimizing for Produc ## 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. +Many of the options described above can be set as command-line arguments. For example, [`optimization.minimize`](/docs/api/options#optimizationminimize) can be set with `--optimization-minimize`, and [`mode`](/docs/api/options#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 index 14cbd401..99e3aa56 100644 --- a/pages/guides/getting-started/concepts/configuration.md +++ b/pages/guides/getting-started/concepts/configuration.md @@ -4,7 +4,7 @@ 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. +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](/docs/api/options). 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: @@ -46,7 +46,7 @@ export default { }; ``` -See the [Configuration section](#TODO[/configuration/]) for every supported configuration option. +See the [Configuration section](/docs/api/options) for every supported configuration option. ## Using multiple configurations @@ -73,12 +73,8 @@ module.exports = [ ## 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]). +In addition to exporting a single configuration as an object, a [function](/guides/core-workflows/environment-variables), or a Promise, you can export 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/entry-points.md b/pages/guides/getting-started/concepts/entry-points.md index db94573d..ef70c751 100644 --- a/pages/guides/getting-started/concepts/entry-points.md +++ b/pages/guides/getting-started/concepts/entry-points.md @@ -97,9 +97,9 @@ 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. +- `library`: specifies [library options](/docs/api/options#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]). +- `publicPath`: a public URL for this entry's output files when they are referenced in a browser. See also [output.publicPath](/docs/api/options#outputpublicpath). ```js displayName="webpack.config.js" export default { @@ -201,7 +201,7 @@ export default { > [!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. +> This is discouraged in webpack 4 and later. Instead, the [`optimization.splitChunks`](/docs/api/options#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 @@ -217,7 +217,7 @@ export default { **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. +**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`](/docs/api/options#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 index b35726f4..45bf286e 100644 --- a/pages/guides/getting-started/concepts/hot-module-replacement.md +++ b/pages/guides/getting-started/concepts/hot-module-replacement.md @@ -34,7 +34,7 @@ Beyond the usual assets, the compiler emits an "update" that allows moving from 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. +The compiler keeps module IDs and chunk IDs consistent between builds. It usually stores these IDs in memory (for example, with [webpack-dev-server](/docs/api/options#devserver)), but they can also be stored in a JSON file. ### In a module @@ -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](/guides/core-workflows/development/hot-module-replacement) for details. +HMR can be used in development as a replacement for LiveReload. [webpack-dev-server](/docs/api/options#devserver) 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 65dfe5b1..9f4e1cdd 100644 --- a/pages/guides/getting-started/concepts/index.md +++ b/pages/guides/getting-started/concepts/index.md @@ -9,7 +9,7 @@ At its core, **webpack** is a _static module bundler_ for modern JavaScript appl > [!TIP] > 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. +Since version 4.0.0, **webpack does not require a configuration file** to bundle your project. Even so, it is [incredibly configurable](/docs/api/options) to better fit your needs. To get started, you only need to understand its **core concepts**: @@ -32,7 +32,7 @@ For a deeper understanding of the ideas behind module bundlers and how they work 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: +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](/docs/api/options#entry). For example: ```js displayName="webpack.config.js" export default { @@ -74,7 +74,7 @@ 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](/guides/getting-started/concepts/output). +> The `output` property has [many more configurable features](/docs/api/options#output). To learn about the concepts behind it, [read more in the output section](/guides/getting-started/concepts/output). ## Loaders @@ -151,7 +151,7 @@ export default { }; ``` -Learn more about the [mode configuration here](#TODO[/configuration/mode]) and which optimizations each value enables. +Learn more about the [mode configuration here](/docs/api/options#mode) and which optimizations each value enables. ## Browser Compatibility diff --git a/pages/guides/getting-started/concepts/loaders.md b/pages/guides/getting-started/concepts/loaders.md index 4f046eca..eb7b8a0f 100644 --- a/pages/guides/getting-started/concepts/loaders.md +++ b/pages/guides/getting-started/concepts/loaders.md @@ -41,7 +41,7 @@ Note that loaders could be used from the CLI in webpack v4, but that feature was ### 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. +[`module.rules`](/docs/api/options#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. @@ -78,7 +78,7 @@ You can specify loaders directly in an `import` statement, or in any equivalent 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: +You can override any loaders, preLoaders, and postLoaders from the [configuration](/docs/api/options) by prefixing the inline `import` statement: - Prefixing with `!` disables all configured normal loaders: diff --git a/pages/guides/getting-started/concepts/manifest.md b/pages/guides/getting-started/concepts/manifest.md index 9958f72c..f3293249 100644 --- a/pages/guides/getting-started/concepts/manifest.md +++ b/pages/guides/getting-started/concepts/manifest.md @@ -18,7 +18,7 @@ The runtime, together with the manifest data, is all the code webpack needs to w ## 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. +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`](/docs/api/options#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 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. diff --git a/pages/guides/getting-started/concepts/module-federation.md b/pages/guides/getting-started/concepts/module-federation.md index 40a2d573..1c2d8f0b 100644 --- a/pages/guides/getting-started/concepts/module-federation.md +++ b/pages/guides/getting-started/concepts/module-federation.md @@ -255,7 +255,7 @@ __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. +> There is also an `'auto'` value available for [`output.publicPath`](/docs/api/options#outputpublicpath) that determines the public path for you automatically. ## Troubleshooting diff --git a/pages/guides/getting-started/concepts/module-resolution.md b/pages/guides/getting-started/concepts/module-resolution.md index d1b0c553..499bf962 100644 --- a/pages/guides/getting-started/concepts/module-resolution.md +++ b/pages/guides/getting-started/concepts/module-resolution.md @@ -46,29 +46,29 @@ 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. +Modules are searched for in every directory listed in [`resolve.modules`](/docs/api/options#resolvemodules). You can substitute a different path for the original module path by defining an alias through the [`resolve.alias`](/docs/api/options#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](/guides/modules-and-dependencies/package-exports). +- If the package contains a `package.json` file, the fields listed in the [`resolve.exportsFields`](/docs/api/options#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: - 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`. +- Otherwise, the extension is resolved using the [`resolve.extensions`](/docs/api/options#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. +- If the folder contains a `package.json` file, the fields listed in the [`resolve.mainFields`](/docs/api/options#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`](/docs/api/options#resolvemainfields) does not yield a valid path, the file names listed in the [`resolve.mainFiles`](/docs/api/options#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`](/docs/api/options#resolveextensions) option. -webpack provides sensible [defaults](#TODO[/configuration/resolve]) for these options based on your build target. +webpack provides sensible [defaults](/docs/api/options#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. +Loader resolution follows the same rules as file resolution. However, the [`resolveLoader`](/docs/api/options#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. +Every filesystem access is cached, so repeated requests to the same file, whether parallel or serial, resolve faster. In [watch mode](/docs/api/options#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. +See the [Resolve API](/docs/api/options#resolve) to learn more about the configuration options mentioned above. diff --git a/pages/guides/getting-started/concepts/output.md b/pages/guides/getting-started/concepts/output.md index 91cdd5ec..33469bfd 100644 --- a/pages/guides/getting-started/concepts/output.md +++ b/pages/guides/getting-started/concepts/output.md @@ -8,7 +8,7 @@ The `output` configuration options tell webpack how to write the compiled files ## 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): +The minimum requirement for the `output` property is to set it to an object and provide an [`output.filename`](/docs/api/options#outputfilename) for the output file(s): ```js displayName="webpack.config.js" export default { @@ -22,7 +22,7 @@ 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: +If your configuration produces more than one "chunk", as happens with multiple entry points or with plugins like `CommonsChunkPlugin`, use [substitutions](/docs/api/options#outputfilename) to give each file a unique name: ```js import path from 'node:path'; diff --git a/pages/guides/getting-started/concepts/targets.md b/pages/guides/getting-started/concepts/targets.md index 07ad871b..566ca0b7 100644 --- a/pages/guides/getting-started/concepts/targets.md +++ b/pages/guides/getting-started/concepts/targets.md @@ -4,7 +4,7 @@ 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]). +Because JavaScript can run on both the server and the browser, webpack offers several deployment _targets_ that you can set in your webpack [configuration](/docs/api/options). > [!WARNING] > 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. @@ -21,14 +21,14 @@ export default { 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/]). +Each target comes with deployment- and environment-specific additions tailored to its needs. See which [targets are available](/docs/api/options#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`: +webpack lets you pass an [array of strings](/docs/api/options#target) 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 { diff --git a/pages/guides/getting-started/concepts/under-the-hood.md b/pages/guides/getting-started/concepts/under-the-hood.md index 81ae9d58..f1c42fd9 100644 --- a/pages/guides/getting-started/concepts/under-the-hood.md +++ b/pages/guides/getting-started/concepts/under-the-hood.md @@ -111,11 +111,11 @@ import( 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 +- [`output.filename`](/docs/api/options#outputfilename) — for `initial` chunk files +- [`output.chunkFilename`](/docs/api/options#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: +A [few placeholders](/docs/api/options#outputfilename) 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 diff --git a/pages/guides/getting-started/index.md b/pages/guides/getting-started/index.md index d02b8ed3..a49bba72 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](/guides/getting-started/installing-webpack), you can interact with webpack through either its [CLI](https://github.com/webpack/webpack-cli) or its [API](#TODO[/api/node]). If you're new to webpack, please read through the [core concepts](/guides/getting-started/concepts) 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](https://github.com/webpack/webpack-cli) or its [API](/docs/api/v5.x). If you're new to webpack, please read through the [core concepts](/guides/getting-started/concepts) 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. @@ -311,7 +311,7 @@ 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. +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](/docs/api/options) to learn more. ## npm scripts @@ -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](/guides/getting-started/concepts) and [configuration](#TODO[/configuration]) pages. Furthermore, the [API](/docs/api/types) 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](/docs/api/options) pages. Furthermore, the [API](/docs/api/types) section digs into the various interfaces webpack offers. diff --git a/pages/guides/migration/to-v3.md b/pages/guides/migration/to-v3.md index e6ae386f..3db76b59 100644 --- a/pages/guides/migration/to-v3.md +++ b/pages/guides/migration/to-v3.md @@ -11,7 +11,7 @@ The sections below walk through the major changes between webpack 1 and webpack ## `resolve.root`, `resolve.fallback`, `resolve.modulesDirectories` -These three options were consolidated into a single `resolve.modules` option. See [resolving](#TODO[/configuration/resolve]) for usage. +These three options were consolidated into a single `resolve.modules` option. See [resolving](/docs/api/options#resolve) for usage. ```diff resolve: { @@ -25,11 +25,11 @@ These three options were consolidated into a single `resolve.modules` option. Se ## `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. +You no longer need to pass an empty string in this option. That behavior moved to `resolve.enforceExtension`. See [resolving](/docs/api/options#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. +Several APIs changed here. They are not documented in detail because they are rarely used. See [resolving](/docs/api/options#resolve) for the specifics. ## `module.loaders` is now `module.rules` @@ -69,7 +69,7 @@ The old loader configuration has been superseded by a more capable rules system ## 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. +As in webpack 1, loaders can be chained so that the output of one is passed to the next. With the [`rule.use`](/docs/api/options#modulerules) 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: { diff --git a/pages/guides/migration/to-v4.md b/pages/guides/migration/to-v4.md index 922b672a..7fb61fd1 100644 --- a/pages/guides/migration/to-v4.md +++ b/pages/guides/migration/to-v4.md @@ -24,7 +24,7 @@ Many third-party plugins need to be updated to their latest versions to be compa ## `mode` -Add the new [`mode`](#TODO[/configuration/mode/]) option to your configuration, setting it to `'production'`, `'development'`, or `'none'` depending on your use case. +Add the new [`mode`](/docs/api/options#mode) option to your configuration, setting it to `'production'`, `'development'`, or `'none'` depending on your use case. ```diff displayName="webpack.config.js" module.exports = { @@ -77,9 +77,9 @@ module.exports = { ## `CommonsChunkPlugin` -`CommonsChunkPlugin` has been removed. Use the [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) options instead. +`CommonsChunkPlugin` has been removed. Use the [`optimization.splitChunks`](/docs/api/options#optimizationsplitchunks) options instead. -See the [`optimization.splitChunks`](#TODO[/configuration/optimization/#optimizationsplitchunks]) documentation for details. The default configuration may already meet your needs. +See the [`optimization.splitChunks`](/docs/api/options#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. @@ -138,7 +138,7 @@ module.exports = { ## `module.loaders` -`module.loaders` was deprecated in webpack 2 and is now removed in favor of [`module.rules`](#TODO[/configuration/module/#rule]). +`module.loaders` was deprecated in webpack 2 and is now removed in favor of [`module.rules`](/docs/api/options#modulerules). ## Further reading diff --git a/pages/guides/migration/to-v5.md b/pages/guides/migration/to-v5.md index 9d86be3e..1c8f3f09 100644 --- a/pages/guides/migration/to-v5.md +++ b/pages/guides/migration/to-v5.md @@ -56,7 +56,7 @@ Because webpack 5 removes all deprecated features, make sure there are no webpac ### 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. +Set `mode` to either [`production`](/docs/api/options#mode) or [`development`](/docs/api/options#mode) so that the corresponding defaults are applied. ### Update outdated options @@ -73,9 +73,9 @@ Update the following options to their new form (if you use them): - `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]) +- `serve` → removed in favor of [`DevServer`](/docs/api/options#devserver) +- [`Rule.query`](/docs/api/options#modulerules) (deprecated since v3) → `Rule.options` / `UseEntry.options` +- `Rule.loaders` → [`Rule.use`](/docs/api/options#modulerules) > [!TIP] > Review the detailed configuration changes [here](/blog/posts/2020-10-10-webpack-5-release/#changes-to-the-configuration). @@ -111,7 +111,7 @@ If you were unable to upgrade some plugins or loaders to their latest versions i ### 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]). +- Consider removing `optimization.moduleIds` and `optimization.chunkIds` from your configuration. The defaults may be better, because they support long-term caching in [`production` mode](/docs/api/options#mode) and easier debugging in [`development` mode](/docs/api/options#mode). - 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/ })`. @@ -195,7 +195,7 @@ Consider removing values that are now defaults: - 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. + 1. Set [`target`](/docs/api/options#target) 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. @@ -306,7 +306,7 @@ Repeat the following steps until you have at least reached level 3 or 4: - 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. + - Source maps are expensive. Check the [`devtool`](/docs/api/options#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. diff --git a/pages/guides/modern-web/index.md b/pages/guides/modern-web/index.md index 4a8f40e6..acdf12c8 100644 --- a/pages/guides/modern-web/index.md +++ b/pages/guides/modern-web/index.md @@ -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](/guides/optimization/code-splitting/#prevent-duplication) for the general idea. +Use [`optimization.splitChunks`](/docs/api/options#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'; @@ -63,11 +63,11 @@ Splitting alone does not change **browser** rules: the tag name must still be re ### 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 `