Update next branch with recent master updates (#2551)

* fix(contribute) Use consistent plugin name in code snippet (#2496)

* fix(configuration) Fix small typo (#2511)

* docs(manifest) Corrections and small update to concept manifest page (#2504)

Small updates and corrections for manifest concepts page

* docs(concepts) Update dependency graph concepts page (#2495)

* docs(concepts) Update dependency graph concepts page

* docs(concepts) Dependency graph minor tweak

* docs(concepts) Use common formatting, provide more links, mention mod… (#2472)

* docs(concepts) use common formatting, provide more links, mention mode in core of the concepts

* docs(concepts) duplicate links on the list for better ux

* docs(concepts) forgot to add EugeneHlushko to contributors

* docs(configuration) Add externals examples (#2515)

Update the external docs with an example on how to combine the different syntaxes. 

I felt it was not clear how to achieve this from the existing docs.

* docs(plugins) Update Writing plugin and Plugin pattern page (#2200)

* Update Writing plugin and Plugin pattern page

* Fixed formatting issues

* Fix markdown lint issues

* Update plugin-patterns.md

* Update plugin-patterns.md

* docs(concepts) Using vendors as entry is not recommended (#2525)

* Using vendors as entry is not recommended

fixes webpack/webpack#6647

* add note about vendor entrypoints

* fix(guides) Correct misspelling and punctuation errors (#2513)

* Correct misspelling and punctuation errors

* Update build-performance.md

* docs(plugins): Add custom vendor chunks using RegEx example (#2518)

* docs(config): Example 3 - custom vendor chunk using RegEx

* docs(config): Example 3 SplitChunks Fenced blank added

* docs(config): (typo) Example 3 - custom vendor chunk using RegEx

* sakhisheikh
docs(config): (reworded) Example 3 - custom vendor chunk using RegEx

* docs(config): (Reword) Example 3 - custom vendor chunk using RegEx

* docs(config): (Reword) Example 3 - custom vendor chunk using RegEx

* chore(plugins) Remove space  (#2527)

* docs(config): Example 3 - custom vendor chunk using RegEx

* squashed everything after c81e77e

* docs(plugins) Add .mjs to the defaults (#2493)

This should be updated once webpack/webpack#7947 is released.

* chore(plugins) Minor SplitChunks Documentation Clean Up (#2252)

* Minor Documentation Clean Up

Originally, i was just trying to change defer => differ, but I ended up doing a bit more editing.

* Lower the case

* fix(api) Clarify module section (#2529)

Change wording from "bind an extension" to "bind a file extension" in order to distinguish from a webpack extension.

_describe your changes..._

- [ ] Read and sign the [CLA][1]. PRs that haven't signed it won't be accepted.
- [ ] Make sure your PR complies with the [writer's guide][2].
- [ ] Review the diff carefully as sometimes this can reveal issues.
- __Remove these instructions from your PR as they are for your eyes only.__


[1]: https://cla.js.foundation/webpack/webpack.js.org
[2]: https://webpack.js.org/writers-guide/

* docs(plugins): Update links in htmlwebpackplugin (#2530)

* docs(plugins) Fix reuseExistingChunk title nesting (#2526)

* docs(plugins) scp reuseExistingChunk title  nesting fix

* docs(plugins) scp reuseExistingChunk title notation

* docs(guides) Fix typo (#2537)

* chore(guides) Import needs to be highlighted with '+' mark (#2536)

import webpack needs to be highlighted since we are adding webpack.HashedModuleIdsPlugin()

* docs(config) Optimization moduleIds option (#2543)

src/content/api/cli.md

@@ -217,11 +217,11 @@ Parameter    | Explanation                                      | Input type | D
 
 These options allow you to bind [modules](/configuration/module/) as allowed by webpack
 
-Parameter            | Explanation                        | Usage
--------------------- | ---------------------------------- | ----------------
-`--module-bind`      | Bind an extension to a loader      | `--module-bind js=babel-loader`
-`--module-bind-post` | Bind an extension to a post loader |
-`--module-bind-pre`  | Bind an extension to a pre loader  |
+Parameter            | Explanation                            | Usage
+-------------------- | -------------------------------------- | ----------------
+`--module-bind`      | Bind a file extension to a loader      | `--module-bind js=babel-loader`
+`--module-bind-post` | Bind a file extension to a post loader |
+`--module-bind-pre`  | Bind a file extension to a pre loader  |
 
 
 ### Watch Options

src/content/concepts/dependency-graph.md

@@ -3,11 +3,17 @@ title: Dependency Graph
 sort: 9
 contributors:
   - TheLarkInn
+  - EugeneHlushko
+related:
+  - title: HTTP2 Aggresive Splitting Example
+    url: https://github.com/webpack/webpack/tree/master/examples/http2-aggressive-splitting
+  - title: webpack & HTTP/2
+    url: https://medium.com/webpack/webpack-http-2-7083ec3f3ce6
 ---
 
 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 config file.
-Starting from these _entry points_, webpack recursively builds a _dependency graph_ that includes every module your application needs, then packages 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, just 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 and bundling through webpack for the [best optimization](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.7y5d3hz59).
+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/entry-points.md

@@ -5,6 +5,7 @@ contributors:
   - TheLarkInn
   - chrisVillanueva
   - byzyk
+  - sokra
 ---
 
 As mentioned in [Getting Started](/guides/getting-started/#using-a-configuration), there are multiple ways to define the `entry` property in your webpack configuration. We will show you the ways you **can** configure the `entry` property, in addition to explaining why it may be useful to you.
@@ -47,7 +48,7 @@ Usage: `entry: {[entryChunkName: string]: string|Array<string>}`
 module.exports = {
   entry: {
     app: './src/app.js',
-    vendors: './src/vendors.js'
+    adminApp: './src/adminApp.js'
   }
 };
 ```
@@ -61,26 +62,9 @@ T> **"Scalable webpack configurations"** are ones that can be reused and combine
 
 Below is a list of entry configurations and their real-world use cases:
 
-
 ### Separate App and Vendor Entries
 
-**webpack.config.js**
-
-```javascript
-module.exports = {
-  entry: {
-    app: './src/app.js',
-    vendors: './src/vendors.js'
-  }
-};
-```
-
-**What does this do?** At face value, this tells webpack to create dependency graphs starting at both `app.js` and `vendors.js`. These graphs are completely separate and independent of each other (there will be a webpack bootstrap in each bundle). This is commonly seen with single page applications which have only one entry point (excluding vendors).
-
-**Why?** This setup allows you to leverage `CommonsChunkPlugin` and extract any vendor references from your app bundle into your vendor bundle, replacing them with `__webpack_require__()` calls. If there is no vendor code in your application bundle, then you can achieve a common pattern in webpack known as [long-term vendor-caching](/guides/caching).
-
-?> Consider removing this scenario in favor of the DllPlugin, which provides a better vendor-splitting.
-
+T> In webpack version < 4 it was common to add vendors as separate entrypoint to compile it as separate file (in combination with the `CommonsChunkPlugin`). This is discouraged in webpack 4. Instead the `optimization.splitChunks` option takes care of separating vendors and app modules and creating a separate file. **Do not** create a entry for vendors or other stuff which is not the starting point of execution.
 
 ### Multi Page Application
 
@@ -100,6 +84,6 @@ module.exports = {
 
 **Why?** In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do multiple things:
 
-- Use `CommonsChunkPlugin` to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the amount of entry points increase.
+- Use `optimization.splitChunks` to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the amount of entry points increase.
 
 T> As a rule of thumb: for each HTML document use exactly one entry point.

src/content/concepts/index.md

@@ -14,22 +14,24 @@ contributors:
   - arjunsajeev
   - byzyk
   - yairhaimo
+  - EugeneHlushko
 ---
 
-At its core, **webpack** is a _static module bundler_ for modern JavaScript applications. When webpack processes your application, it internally builds a _dependency graph_ which maps every module your project needs and generates one or more _bundles_.
+At its core, __webpack__ is a _static module bundler_ for modern JavaScript applications. When webpack processes your application, it internally builds a [dependency graph](/concepts/dependency-graph/) which maps every module your project needs and generates one or more _bundles_.
 
 T> Learn more about JavaScript modules and webpack modules [here](/concepts/modules).
 
-Since version 4.0.0, **webpack does not require a configuration file** to bundle your project, nevertheless it is [incredibly configurable](/configuration) to better fit your needs.
+Since version 4.0.0, __webpack does not require a configuration file__ to bundle your project, nevertheless it is [incredibly configurable](/configuration) to better fit your needs.
 
-To get started you only need to understand its **Core Concepts**:
+To get started you only need to understand its __Core Concepts__:
 
-- Entry
-- Output
-- Loaders
-- Plugins
+- [Entry](#entry)
+- [Output](#output)
+- [Loaders](#loaders)
+- [Plugins](#plugins)
+- [Mode](#mode)
 
-This document is intended to give a **high-level** overview of these concepts, while providing links to detailed concept specific use cases.
+This document is intended to give a __high-level__ overview of these concepts, while providing links to detailed concept specific use cases.
 
 For a better understanding of the ideas behind module bundlers and how they work under the hood consult these resources:
 
@@ -40,9 +42,9 @@ For a better understanding of the ideas behind module bundlers and how they work
 
 ## Entry
 
-An **entry point** indicates which module webpack should use to begin building out its internal *dependency graph*. webpack will figure out which other modules and libraries that entry point depends on (directly and indirectly).
+An __entry point__ indicates which module webpack should use to begin building out its internal [dependency graph](/concepts/dependency-graph/). webpack will figure out which other modules and libraries that entry point depends on (directly and indirectly).
 
-By default its value is `./src/index.js`, but you can specify a different (or multiple entry points) by configuring the **entry** property in the [webpack configuration](/configuration). For example:
+By default its value is `./src/index.js`, but you can specify a different (or multiple entry points) by configuring the __entry__ property in the [webpack configuration](/configuration). For example:
 
 __webpack.config.js__
 
@@ -57,7 +59,7 @@ T> Learn more in the [entry points](/concepts/entry-points) section.
 
 ## Output
 
-The **output** property tells webpack where to emit the *bundles* it creates and how to name these files. It defaults to `./dist/main.js` for the main output file and to the `./dist` folder for any other generated file.
+The __output__ property tells webpack where to emit the *bundles* it creates and how to name these files. It defaults to `./dist/main.js` for the main output file and to the `./dist` folder for any other generated file.
 
 You can configure this part of the process by specifying an `output` field in your configuration:
 
@@ -82,11 +84,11 @@ T> The `output` property has [many more configurable features](/configuration/ou
 
 ## Loaders
 
-Out of the box, webpack only understands JavaScript files. **Loaders** allow webpack to process other types of files and convert them into valid [modules](/concepts/modules) that can be consumed by your application and added to the dependency graph.
+Out of the box, webpack only understands JavaScript files. __Loaders__ allow webpack to process other types of files and convert them into valid [modules](/concepts/modules) that can be consumed by your application and added to the dependency graph.
 
 W> Note that the ability to `import` any type of module, e.g. `.css` files, is a feature specific to webpack and may not be supported by other bundlers or task runners. We feel this extension of the language is warranted as it allows developers to build a more accurate dependency graph.
 
-At a high level, **loaders** have two properties in your webpack configuration:
+At a high level, __loaders__ have two properties in your webpack configuration:
 
 1. The `test` property identifies which file or files should be transformed.
 2. The `use` property indicates which loader should be used to do the transforming.
@@ -110,7 +112,7 @@ module.exports = {
 
 The configuration above has defined a `rules` property for a single module with two required properties: `test` and `use`. This tells webpack's compiler the following:
 
-> "Hey webpack compiler, when you come across a path that resolves to a '.txt' file inside of a `require()`/`import` statement, **use** the `raw-loader` to transform it before you add it to the bundle."
+> "Hey webpack compiler, when you come across a path that resolves to a '.txt' file inside of a `require()`/`import` statement, __use__ the `raw-loader` to transform it before you add it to the bundle."
 
 W> It is important to remember that when defining rules in your webpack config, you are defining them under `module.rules` and not `rules`. For your benefit, webpack will warn you if this is done incorrectly.
 
@@ -125,7 +127,7 @@ T> Check out the [plugin interface](/api/plugins) and how to use it to extend we
 
 In order to use a plugin, you need to `require()` it and add it to the `plugins` array. Most plugins are customizable through options. Since you can use a plugin multiple times in a config for different purposes, you need to create an instance of it by calling it with the `new` operator.
 
-**webpack.config.js**
+__webpack.config.js__
 
 ```javascript
 const HtmlWebpackPlugin = require('html-webpack-plugin'); //installed via npm

src/content/concepts/manifest.md

@@ -3,32 +3,33 @@ title: The Manifest
 sort: 10
 contributors:
   - skipjack
+  - EugeneHlushko
 related:
   - title: Separating a Manifest
     url: https://survivejs.com/webpack/optimizing/separating-manifest/
   - title: Predictable Long Term Caching with Webpack
     url: https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31
   - title: Caching
-    url: /guides/caching
+    url: /guides/caching/
 ---
 
 In a typical application or site built with webpack, there are three main types of code:
 
 1. The source code you, and maybe your team, have written.
 2. Any third-party library or "vendor" code your source is dependent on.
-3. A webpack runtime and _manifest_ that conducts the interaction of all modules.
+3. A webpack runtime and __manifest__ that conducts the interaction of all modules.
 
 This article will focus on the last of these three parts, the runtime and in particular the manifest.
 
 
 ## Runtime
 
-As mentioned above, we'll only briefly touch on this. 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 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.
 
 
 ## Manifest
 
-So, once your application hits the browser in the form of an `index.html` file, some bundles, and a variety of other assets, what does it look like? That `/src` directory you meticulously laid out is now gone, so how does webpack manage the interaction between all of your modules? This is where the manifest data comes in...
+Once your application hits the browser in the form of `index.html` file, some bundles and a variety of other assets required by your application must be loaded and linked somehow. That `/src` directory you meticulously laid out is now bundled, minified and maybe even splitted into smaller chunks for lazy-loading by webpack's [`optimization`](/configuration/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 your modules. This collection of data is called the "Manifest" and it's what the runtime will use to resolve and load modules once they've been bundled and shipped to the browser. No matter which [module syntax](/api/module-methods) you have chosen, those `import` or `require` statements have now become `__webpack_require__` methods that point to module identifiers. Using the data in the manifest, the runtime will be able to find out where to retrieve the modules behind the identifiers.
 
@@ -39,4 +40,4 @@ So now you have a little bit of insight about how webpack works behind the scene
 
 By using content hashes within your bundle file names, you can indicate to the browser when the contents 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 contents apparently do not. This is caused by the injection of the runtime and manifest which changes every build.
 
-See [the manifest section](/guides/output-management#the-manifest) of our _Managing Built Files_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long term caching.
+See [the manifest section](/guides/output-management/#the-manifest) of our _Output management_ guide to learn how to extract the manifest, and read the guides below to learn more about the intricacies of long term caching.

src/content/configuration/externals.md

@@ -7,6 +7,7 @@ contributors:
   - pksjce
   - fadysamirsadek
   - byzyk
+  - zefman
 ---
 
 The `externals` configuration option provides a way of excluding dependencies from the output bundles. Instead, the created bundle relies on that dependency to be present in the consumer's environment. This feature is typically most useful to __library developers__, however there are a variety of applications for it.
@@ -148,5 +149,37 @@ module.exports = {
 
 In this case any dependency named `jQuery`, capitalized or not, or `$` would be externalized.
 
+### Combining syntaxes
+
+Sometimes you may want to use a combination of the above syntaxes. This can be done in the following manner:
+
+```js
+module.exports = {
+  //...
+  externals: [
+    {
+      // String
+      react: 'react',
+      // Object
+      lodash : {
+        commonjs: 'lodash',
+        amd: 'lodash',
+        root: '_' // indicates global variable
+      },
+      // Array
+      subtract: ['./math', 'subtract']
+    },
+    // Function
+    function(context, request, callback) {
+      if (/^yourregex$/.test(request)){
+        return callback(null, 'commonjs ' + request);
+      }
+      callback();
+    },
+    // Regex
+    /^(jquery|\$)$/i
+  ]
+};
+```
 
 For more information on how to use this configuration, please refer to the article on [how to author a library](/guides/author-libraries).

src/content/configuration/optimization.md

@@ -177,6 +177,33 @@ module.exports = {
 };
 ```
 
+## `optimization.moduleIds`
+
+`bool: false` `string: natural, named, hashed, size, total-size`
+
+Tells webpack which algorithm to use when choosing module ids. Setting `optimization.moduleIds` to `false` tells webpack that none of built-in algorithms should be used, as custom one can be provided via plugin. By default `optimization.moduleIds` is set to `false`.
+
+The following string values are supported:
+
+Option                | Description
+--------------------- | -----------------------
+`natural`             | Numeric ids in order of usage.
+`named`               | Readable ids for better debugging.
+`hashed`              | Short hashes as ids for better long term caching.
+`size`                | Numeric ids focused on minimal initial download size.
+`total-size`          | numeric ids focused on minimal total download size.
+
+__webpack.config.js__
+
+```js
+module.exports = {
+  //...
+  optimization: {
+    moduleIds: 'hashed'
+  }
+};
+```
+
 ## `optimization.nodeEnv`
 
 `string` `bool: false`

src/content/configuration/output.md

@@ -429,7 +429,7 @@ module.exports = {
 
 The variable `MyLibrary` will be bound with the return value of your entry file, if the resulting output is included as a script tag in an HTML page.
 
-W> Note that if an `array` is provided as an `entry` point, only the last module in the array will be exposed. If an `object` is provided, it can exposed using an `array` syntax (see [this example](https://github.com/webpack/webpack/tree/master/examples/multi-part-library) for details).
+W> Note that if an `array` is provided as an `entry` point, only the last module in the array will be exposed. If an `object` is provided, it can be exposed using an `array` syntax (see [this example](https://github.com/webpack/webpack/tree/master/examples/multi-part-library) for details).
 
 T> Read the [authoring libraries guide](/guides/author-libraries) guide for more information on `output.library` as well as `output.libraryTarget`.