docs(general): Revise "imposter syndrome" language (#5016)

Author: SeanKilleen

src/content/api/cli.md

@@ -29,13 +29,13 @@ related:
     url: https://medium.com/@nimgrg/analysing-and-minimising-the-size-of-client-side-bundle-with-webpack-and-source-map-explorer-41096559beca#.c3t2srr8x
 ---
 
-For proper usage and easy distribution of this configuration, webpack can be configured with `webpack.config.js`. Any parameters sent to the CLI will map to a corresponding parameter in the configuration file.
+For proper usage and easier distribution of this configuration, webpack can be configured with `webpack.config.js`. Any parameters sent to the CLI will map to a corresponding parameter in the configuration file.
 
 Read the [installation guide](/guides/installation) if you don't already have webpack and CLI installed.
 
 ## Commands
 
-webpack-cli offers a variety of commands to make working with webpack easy. By default webpack ships with
+webpack-cli offers a variety of commands to make working with webpack easier. By default webpack ships with
 
 | Command                               | Usage                                                 | Description                                                                     |
 | ------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------- |
@@ -314,7 +314,7 @@ npx webpack help --mode
 
 **Show version of installed packages and sub-packages**
 
-To inspect the version of `webpack` and `webpack-cli` you are using just run command:
+To inspect the version of `webpack` and `webpack-cli` you are using, run the command:
 
 ```bash
 npx webpack --version
@@ -339,7 +339,7 @@ webpack-cli 4.6.0
 webpack-dev-server 3.11.2
 ```
 
-To inspect the version of any `webpack-cli` sub-package (like `@webpack-cli/info`) just run command similar to the following:
+To inspect the version of any `webpack-cli` sub-package (like `@webpack-cli/info`), run command similar to the following:
 
 ```bash
 npx webpack info --version

src/content/api/compilation-hooks.mdx

@@ -389,7 +389,7 @@ Any additional chunk assets are stored in `compilation.additionalChunkAssets`.
 
 - Callback Parameters: `chunks`
 
-Here's an example that simply adds a banner to each chunk.
+Here's an example that adds a banner to each chunk.
 
 ```js
 compilation.hooks.optimizeChunkAssets.tapAsync(

src/content/api/index.md

@@ -14,7 +14,7 @@ The following high-level information should get you started.
 
 The Command Line Interface (CLI) to configure and interact with your build. It
 is especially useful in the case of early prototyping and profiling. For the
-most part, the CLI is simply used to kick off the process using a configuration
+most part, the CLI is used to kick off the process using a configuration
 file and a few flags (e.g. `--env`).
 
 [Learn more about the CLI!](/api/cli)
@@ -29,7 +29,7 @@ and [variables](/api/module-variables) – that are supported.
 
 ## Node
 
-While most users can get away with just using the CLI along with a
+While most users can get away with using the CLI along with a
 configuration file, more fine-grained control of the compilation can be
 achieved via the Node interface. This includes passing multiple configurations,
 programmatically running or watching, and collecting stats.

src/content/api/loaders.mdx

@@ -16,7 +16,7 @@ contributors:
   - jamesgeorge007
 ---
 
-A loader is just a JavaScript module that exports a function. The [loader runner](https://github.com/webpack/loader-runner) calls this function and passes the result of the previous loader or the resource file into it. The `this` context of the function is filled-in by webpack and the [loader runner](https://github.com/webpack/loader-runner) with some useful methods that allow the loader (among other things) to change its invocation style to async, or get query parameters.
+A loader is a JavaScript module that exports a function. The [loader runner](https://github.com/webpack/loader-runner) calls this function and passes the result of the previous loader or the resource file into it. The `this` context of the function is filled-in by webpack and the [loader runner](https://github.com/webpack/loader-runner) with some useful methods that allow the loader (among other things) to change its invocation style to async, or get query parameters.
 
 The first loader is passed one argument: the content of the resource file. The compiler expects a result from the last loader. The result should be a `String` or a `Buffer` (which is converted to a string), representing the JavaScript source code of the module. An optional SourceMap result (as a JSON object) may also be passed.
 
@@ -50,7 +50,7 @@ module.exports = function (content, map, meta) {
 };
 ```
 
-The `this.callback` method is more flexible as it allows multiple arguments to be passed as opposed to just the `content`.
+The `this.callback` method is more flexible as it allows multiple arguments to be passed as opposed to only the `content`.
 
 **sync-loader-with-multiple-results.js**
 

src/content/api/module-methods.mdx

@@ -297,7 +297,7 @@ W> This CANNOT be used in an asynchronous function.
 define(value: !Function)
 ```
 
-This will simply export the provided `value`. The `value` here can be anything except a function.
+This will export the provided `value`. The `value` here can be anything except a function.
 
 ```javascript
 define({
@@ -445,7 +445,7 @@ if (require.cache[require.resolveWeak('module')]) {
 }
 
 // You can perform dynamic resolves ("context")
-// just as with other require/import methods.
+// similarly to other require/import methods.
 const page = 'Foo';
 __webpack_modules__[require.resolveWeak(`./page/${page}`)];
 ```

src/content/api/node.mdx

@@ -72,7 +72,7 @@ webpack runner or have it build and watch for changes, much like the
 
 Typically, only one master `Compiler` instance is created, although child
 compilers can be created in order to delegate specific tasks. The `Compiler` is
-ultimately just a function which performs bare minimum functionality to keep a
+ultimately a function which performs bare minimum functionality to keep a
 lifecycle running. It delegates all the loading, bundling, and writing work to
 registered plugins.
 
@@ -144,8 +144,8 @@ const watching = compiler.watch({
 `Watching` options are covered in detail
 [here](/configuration/watch/#watchoptions).
 
-W> Filesystem inaccuracies may trigger multiple builds for a single change. So,
-in the example above, the `console.log` statement may fire multiple times for a
+W> Filesystem inaccuracies may trigger multiple builds for a single change.
+In the example above, the `console.log` statement may fire multiple times for a
 single modification. Users should expect this behavior and may check
 `stats.hash` to see if the file hash has actually changed.
 

src/content/api/plugins.md

@@ -88,7 +88,7 @@ The moral of the story is that there are a variety of ways to `hook` into the
 ## Custom Hooks
 
 In order to add a new hook to the compilation for other plugins to `tap` into,
-simply `require` the necessary hook class from `tapable` and create one:
+you then `require` the necessary hook class from `tapable` and create one:
 
 ```js
 const SyncHook = require('tapable').SyncHook;

src/content/blog/2020-10-10-webpack-5-release.md

@@ -98,7 +98,7 @@ Behavior can be changed with `Rule.parser.requireInclude` to allowed, deprecated
 
 In the early days, webpack's aim was to allow running most Node.js modules in the browser, but the module landscape changed and many module uses are now written mainly for frontend purposes. webpack <= 4 ships with polyfills for many of the Node.js core modules, which are automatically applied once a module uses any of the core modules (i.e. the `crypto` module).
 
-While this makes using modules written for Node.js easy, it adds these huge polyfills to the bundle. In many cases these polyfills are unnecessary.
+While this makes using modules written for Node.js easier, it adds these huge polyfills to the bundle. In many cases these polyfills are unnecessary.
 
 webpack 5 stops automatically polyfilling these core modules and focus on frontend-compatible modules. Our goal is to improve compatibility with the web platform, where Node.js core modules are not available.
 
@@ -253,7 +253,7 @@ Webpack 5 allows to pass a list of targets and also support versions of target.
 
 Examples: `target: "node14"` `target: ["web", "es2020"]`
 
-This is a simple way to provide webpack all the information it needs to determine:
+This enables us to provide webpack all the information it needs to determine:
 
 - chunk loading mechanism, and
 - supported syntax like arrow functions

src/content/blog/2020-12-08-roadmap-2021.md

@@ -26,7 +26,7 @@ A potential fix would be to include the side-effect-free module in all entrypoin
 So we went another route, which required the development of a new feature: `runtime-dependent code generation`.
 This allows to generate code which behaves differently depending on which runtime it executes.
 
-Basically, we are wrapping some generated code in `if`-blocks, so they only execute in one runtime.
+To put it another way, we are wrapping some generated code in `if`-blocks, so they only execute in one runtime.
 In this example, this would affect the `import`-statement which references the side-effect-free module.
 The import is only executed for one of the entrypoints.
 This avoids to include unnecessary modules, and it also avoids executing unnecessary code even if it would be available.
@@ -50,7 +50,7 @@ We think that many many webpack users need custom things for their build and tha
 ### EcmaScript Modules
 
 EcmaScript Modules (ESM) are slowly gaining wide-spread adoption.
-On authoring side they are basically already the go-to standard to write code.
+On authoring side they are already the de facto standard to write code.
 On browser support it also looks pretty ok (except for IE11 and a few older mobile browsers).
 Browsers are still a bit lacking in supporting ESM for WebWorkers.
 
@@ -118,7 +118,7 @@ The biggest problem is the `"sideEffects": false` flag. It affects modules on pe
 When the output should be a library that will be processed by a bundler later, this needs to be considered.
 
 I could think of a special mode, which does not apply chunking and instead, emit the raw (processed) modules connected via ESM imports and exports (or also CommonJS `require`).
-So this basically means loaders, module graph, and asset optimizations run, but no chunk graph is created and each module in the module graph is emitted as a separate file.
+So this means loaders, module graph, and asset optimizations run, but no chunk graph is created and each module in the module graph is emitted as a separate file.
 
 #### Strict mode warnings
 
@@ -144,7 +144,7 @@ Currently webpack supports CSS via `css-loader`, `style-loader` or `mini-css-ext
 This is working pretty well, but I think we can do more by supporting CSS as a native module type in webpack.
 
 A major benefit would be the developer experience: The `mini-css-extract-plugin` configuration is not the easiest and getting rid of it would simplify a lot for the developer.
-Of course, that doesn't mean you can add additional customization on top of that.
+That doesn't mean you can add additional customization on top of that.
 I see many developers not using raw CSS, but using preprocessors on top of that (with native CSS support this would look like that: `{ test: /\.sass$/, type: "stylesheet", use: "sass-loader" }`).
 
 As of [State of CSS 2020](https://2020.stateofcss.com/en-US/technologies/css-in-js/) CSS Modules is a popular way of writing modular CSS and it being a native module type in webpack allows to benefit from module graph optimization like Tree Shaking (Used Exports Optimization and Side-Effects optimization). When using CSS Modules this means the resulting CSS will only contain CSS rules that are referenced from the application (as one is used to from JS Tree Shaking).

src/content/branding.md

@@ -22,7 +22,7 @@ The webpack logo should be placed on a white background with enough space around
 
 [svg](https://github.com/webpack/media/blob/master/logo/logo-on-white-bg.svg) | [png](https://github.com/webpack/media/blob/master/logo/logo-on-white-bg.png) | [jpg](https://github.com/webpack/media/blob/master/logo/logo-on-white-bg.jpg)
 
-Just double the size of the inner dark blue cube to get an idea how much space the logo should have.
+Double the size of the inner dark blue cube to get an idea how much space the logo should have.
 
 For dark backgrounds, you can use the negative version of the logo:
 

src/content/concepts/configuration.md

@@ -30,7 +30,7 @@ T> The most important part to take away from this document is that there are man
 
 The examples below describe how webpack's configuration can be both expressive and configurable because _it is code_:
 
-## Simple Configuration
+## Introductory Configuration
 
 **webpack.config.js**
 

src/content/concepts/dependency-graph.md

@@ -14,6 +14,6 @@ related:
 Any time one file depends on another, webpack treats this as a _dependency_. This allows webpack to take non-code assets, such as images or web fonts, and also provide them as _dependencies_ for your application.
 
 When webpack processes your application, it starts from a list of modules defined on the command line or in its configuration file.
-Starting from these [_entry points_](/concepts/entry-points/), webpack recursively builds a _dependency graph_ that includes every module your application needs, then bundles all of those modules into a small number of _bundles_ - often, just one - to be loaded by the browser.
+Starting from these [_entry points_](/concepts/entry-points/), webpack recursively builds a _dependency graph_ that includes every module your application needs, then bundles all of those modules into a small number of _bundles_ - often, only one - to be loaded by the browser.
 
 T> Bundling your application is especially powerful for _HTTP/1.1_ clients, as it minimizes the number of times your app has to wait while the browser starts a new request. For _HTTP/2_, you can also use [Code Splitting](/guides/code-splitting/) to achieve best results.

src/content/concepts/manifest.md

@@ -23,7 +23,7 @@ This article will focus on the last of these three parts: the runtime and, in pa
 
 ## Runtime
 
-The runtime, along with the manifest data, is basically all the code webpack needs to connect your modularized application while it's running in the browser. It contains the loading and resolving logic needed to connect your modules as they interact. This includes connecting modules that have already been loaded into the browser as well as logic to lazy-load the ones that haven't.
+The runtime, along with the manifest data, is all the code webpack needs to connect your modularized application while it's running in the browser. It contains the loading and resolving logic needed to connect your modules as they interact. This includes connecting modules that have already been loaded into the browser as well as logic to lazy-load the ones that haven't.
 
 ## Manifest
 
@@ -33,7 +33,7 @@ As the compiler enters, resolves, and maps out your application, it keeps detail
 
 ## The Problem
 
-So now you have a little bit of insight about how webpack works behind the scenes. "But, how does this affect me?", you might ask. The simple answer is that most of the time it doesn't. The runtime will do its thing, utilizing the manifest, and everything will appear to just magically work once your application hits the browser. However, if you decide to improve the performance of your projects by utilizing browser caching, this process will all of a sudden become an important thing to understand.
+So now you have a little bit of insight about how webpack works behind the scenes. "But, how does this affect me?", you might ask. Most of the time, it doesn't. The runtime will do its thing, utilizing the manifest, and everything will appear to magically work once your application hits the browser. However, if you decide to improve the performance of your projects by utilizing browser caching, this process will all of a sudden become an important thing to understand.
 
 By using content hashes within your bundle file names, you can indicate to the browser when the content of a file has changed, thus invalidating the cache. Once you start doing this though, you'll immediately notice some funny behavior. Certain hashes change even when their content apparently does not. This is caused by the injection of the runtime and manifest, which changes every build.
 

src/content/concepts/targets.md

@@ -16,7 +16,7 @@ W> The webpack `target` property is not to be confused with the `output.libraryT
 
 ## Usage
 
-To set the `target` property, you simply set the target value in your webpack config:
+To set the `target` property, you set the target value in your webpack config:
 
 **webpack.config.js**
 

src/content/concepts/why-webpack.md

@@ -18,7 +18,7 @@ IIFEs solve scoping issues for large projects; when script files are wrapped by
 
 The use of IIFEs led to tools like Make, Gulp, Grunt, Broccoli or Brunch. These tools are known as task runners, and they concatenate all your project files together.
 
-However, changing one file means you have to rebuild the whole thing. Concatenating makes it easy to reuse scripts across files but makes build optimizations more difficult. How can you find out if code is actually being used or not?
+However, changing one file means you have to rebuild the whole thing. Concatenating makes it easier to reuse scripts across files but makes build optimizations more difficult. How can you find out if code is actually being used or not?
 
 Even if you only use a single function from lodash, you have to add the entire library and then squish it together. How do you treeshake the dependencies on your code? Lazy loading chunks of code can be hard to do at scale and requires a lot of manual work from the developer.
 

src/content/configuration/configuration-languages.md

@@ -32,7 +32,7 @@ and then proceed to write your configuration:
 ```typescript
 import * as path from 'path';
 import * as webpack from 'webpack';
-// just in case you run into any typescript error when configuring `devServer`
+// in case you run into any typescript error when configuring `devServer`
 import 'webpack-dev-server';
 
 const config: webpack.Configuration = {

src/content/configuration/dev-server.md

@@ -32,7 +32,7 @@ T> Options that are compatible with [webpack-dev-middleware](https://github.com/
 
 `object`
 
-This set of options is picked up by [webpack-dev-server](https://github.com/webpack/webpack-dev-server) and can be used to change its behavior in various ways. Here's a simple example that gzips and serves everything from our `dist/` directory in the project root:
+This set of options is picked up by [webpack-dev-server](https://github.com/webpack/webpack-dev-server) and can be used to change its behavior in various ways. Here's a rudimentary example that gzips and serves everything from our `dist/` directory in the project root:
 
 **webpack.config.js**
 

src/content/configuration/entry-context.md

@@ -42,7 +42,7 @@ The point or points where to start the application bundling process. If an array
 
 A dynamically loaded module is **not** an entry point.
 
-Simple rule: one entry point per HTML page. SPA: one entry point, MPA: multiple entry points.
+A rule to consider: one entry point per HTML page. SPA: one entry point, MPA: multiple entry points.
 
 ```js
 module.exports = {

src/content/configuration/module.mdx

@@ -466,7 +466,7 @@ Parsers may inspect these options and disable or reconfigure themselves accordin
 - Setting the option to `false` disables the parser.
 - Setting the option to `true` or leaving it `undefined` enables the parser.
 
-However, parser plugins may accept more than just a boolean. For example, the internal `NodeStuffPlugin` can accept an object instead of `true` to add additional options for a particular Rule.
+However, parser plugins may accept more than only a boolean. For example, the internal `NodeStuffPlugin` can accept an object instead of `true` to add additional options for a particular Rule.
 
 **Examples** (parser options by the default plugins):
 

src/content/configuration/other-options.mdx

@@ -531,7 +531,7 @@ T> Combine `profile: true` with `parallelism: 1` to get correct timings. Note th
 
 `string`
 
-Use this option to generate a JSON file containing webpack "records" – pieces of data used to store module identifiers across multiple builds. You can use this file to track how modules change between builds. To generate one, simply specify a location:
+Use this option to generate a JSON file containing webpack "records" – pieces of data used to store module identifiers across multiple builds. You can use this file to track how modules change between builds. To generate one, specify a location:
 
 **webpack.config.js**