diff --git a/pages/guides/core-workflows/production.md b/pages/guides/core-workflows/production.md index e24458bc..644cffdf 100644 --- a/pages/guides/core-workflows/production.md +++ b/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: diff --git a/pages/guides/getting-started/concepts/entry-points.md b/pages/guides/getting-started/concepts/entry-points.md index 0eaace26..17328d9f 100644 --- a/pages/guides/getting-started/concepts/entry-points.md +++ b/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 diff --git a/pages/guides/getting-started/concepts/loaders.md b/pages/guides/getting-started/concepts/loaders.md index 7cabaeec..79190491 100644 --- a/pages/guides/getting-started/concepts/loaders.md +++ b/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. diff --git a/pages/guides/getting-started/index.md b/pages/guides/getting-started/index.md index c448ea42..2f01755a 100644 --- a/pages/guides/getting-started/index.md +++ b/pages/guides/getting-started/index.md @@ -169,7 +169,7 @@ pnpm add lodash ``` > [!TIP] -> With npm 5 and later, packages installed with `npm install ` 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 ` 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 --git a/pages/guides/getting-started/installing-webpack.md b/pages/guides/getting-started/installing-webpack.md index 5f3bbc73..2a2e29f9 100644 --- a/pages/guides/getting-started/installing-webpack.md +++ b/pages/guides/getting-started/installing-webpack.md @@ -28,7 +28,7 @@ npm install --save-dev webpack@ > [!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 diff --git a/pages/guides/migration/index.md b/pages/guides/migration/index.md index 627e6904..c28c830f 100644 --- a/pages/guides/migration/index.md +++ b/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/) diff --git a/pages/guides/optimization/build-performance.md b/pages/guides/optimization/build-performance.md index 87da20af..c03e6e65 100644 --- a/pages/guides/optimization/build-performance.md +++ b/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 diff --git a/pages/guides/optimization/caching.md b/pages/guides/optimization/caching.md index 74048694..671f9386 100644 --- a/pages/guides/optimization/caching.md +++ b/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 diff --git a/pages/guides/optimization/code-splitting/index.md b/pages/guides/optimization/code-splitting/index.md index af9d7b4e..a04249cb 100644 --- a/pages/guides/optimization/code-splitting/index.md +++ b/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: diff --git a/pages/guides/optimization/tree-shaking.md b/pages/guides/optimization/tree-shaking.md index e5ab8fdd..83419bdd 100644 --- a/pages/guides/optimization/tree-shaking.md +++ b/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.