docs(guides): drop webpack 4 and legacy npm references

pages/guides/core-workflows/production.md

@@ -127,7 +127,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`](/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):
+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. 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';
@@ -166,7 +166,7 @@ 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](/docs/api/options#mode).
+webpack 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:
 

pages/guides/getting-started/concepts/entry-points.md

@@ -200,9 +200,7 @@ export default {
 **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`](/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.
+> Avoid adding vendors as a separate entry point. 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
 

pages/guides/getting-started/concepts/loaders.md

@@ -38,8 +38,6 @@ 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`](/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.

pages/guides/getting-started/index.md

@@ -169,7 +169,7 @@ 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).
+> 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:
 

pages/guides/getting-started/installing-webpack.md

@@ -28,7 +28,7 @@ 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](https://github.com/webpack/webpack-cli#how-to-install):
+To call `webpack` from the command line, you'll also need to install the [CLI](https://github.com/webpack/webpack-cli#how-to-install):
 
 ```bash
 npm install --save-dev webpack-cli
@@ -43,7 +43,7 @@ Installing locally is what we recommend for most projects. It makes it easier to
 ```
 
 > [!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`.
+> To run a local installation of webpack, you can access its binary at `node_modules/.bin/webpack`. Alternatively, you can run `npx webpack`.
 
 ## Global installation
 

pages/guides/migration/index.md

@@ -6,3 +6,7 @@ authors: EugeneHlushko,avivkeller
 # Migrate
 
 This section covers how to migrate from older versions of webpack to newer ones.
+
+Documentation for older versions of webpack is not maintained, but is available as a static snapshot. Use these versions of the docs if you are unable to upgrade your project, but still wish to consult guides and reference:
+
+- [webpack 4 documentation](https://v4.webpack.js.org/)

pages/guides/optimization/build-performance.md

@@ -128,7 +128,7 @@ These utilities improve performance by compiling and serving assets from memory
 
 ### 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.
+By default, webpack emits a large amount of data through `stats.toJson()`. Avoid reading parts of the `stats` object unless you need them in the incremental step.
 
 ### Devtool
 

pages/guides/optimization/caching.md

@@ -113,7 +113,7 @@ Run another build to see the extracted `runtime` bundle:
 
 ```bash
 Hash: 82c9c385607b2150fab2
-Version: webpack 4.12.0
+Version: webpack 5.107.2
 Time: 3027ms
                           Asset       Size  Chunks             Chunk Names
 runtime.cc17ae2a94ec771e9221.js   1.42 KiB       0  [emitted]  runtime

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

@@ -303,7 +303,7 @@ Now, instead of statically importing `lodash`, we'll use a dynamic import to spl
 +});
 ```
 
-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).
+We need `default` here because importing a CommonJS module with `import()` doesn't resolve to the value of `module.exports`; instead, webpack creates an artificial namespace object for the CommonJS module.
 
 Run webpack to see `lodash` split out into a separate bundle:
 
@@ -412,7 +412,7 @@ The following comments are supported:
 
 ## Prefetching/Preloading modules
 
-webpack 4.6.0+ adds support for prefetching and preloading.
+webpack supports prefetching and preloading of modules.
 
 Using these inline directives when declaring your imports lets webpack output a "Resource Hint" that tells the browser:
 

pages/guides/optimization/tree-shaking.md

@@ -7,7 +7,7 @@ authors: simon04,zacanger,alexjoverm,avant1,MijaelWatts,dmitriid,probablyup,gish
 
 _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.
+webpack has built-in support for ES2015 modules (also known as _harmony modules_) along with detection of unused module exports, and lets 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](/guides/getting-started). If you haven't read through that guide yet, please do so now.