Use renderder GitHub pages links

src/content/api/cli.md

@@ -8,6 +8,7 @@ contributors:
   - chenxsan
   - rencire
   - madhavarshney
+  - EugeneHlushko
 related:
   - title: Analyzing Build Statistics
     url: https://survivejs.com/webpack/optimizing-build/analyzing-build-statistics/
@@ -23,11 +24,6 @@ related:
 
 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 config file.
 
-Users have a choice between two CLI packages:
-
-* [webpack-cli](https://github.com/webpack/webpack-cli): the original webpack full-featured CLI.
-* [webpack-command](https://github.com/webpack-contrib/webpack-command): the lightweight, opinionated and modern CLI.
-
 Read the [installation guide](/guides/installation) if you don't already have webpack and CLI installed.
 
 
@@ -221,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/api/plugins.md

@@ -99,6 +99,38 @@ compiler.hooks.myCustomHook.call(a, b, c);
 Again, see the [documentation](https://github.com/webpack/tapable) for `tapable` to learn more about the
 different hook classes and how they work.
 
+## Reporting Progress
+
+Plugins can report progress via [`ProgressPlugin`](/plugins/progress-plugin/), which prints progress messages to stderr by default. In order to enable progress reporting, pass a `--progress` argument when running the [webpack CLI](/api/cli/).
+
+It is possible to customize the printed output by passing different arguments to the `reportProgress` function of [`ProgressPlugin`](/plugins/progress-plugin/).
+
+To report progress, a plugin must `tap` into a hook using the `context: true` option:
+
+```js
+compiler.hooks.emit.tapAsync({
+  name: 'MyPlugin',
+  context: true
+}, (context, compiler, callback) => {
+  const reportProgress = context && context.reportProgress;
+  if (reportProgress) reportProgress(0.95, 'Starting work');
+  setTimeout(() => {
+    if (reportProgress) reportProgress(0.95, 'Done work');
+    callback();
+  }, 1000);
+});
+```
+
+The `reportProgress` function may be called with these arguments:
+
+```js
+reportProgress(percentage, ...args);
+```
+
+* `percentage`: This argument is unused; instead, [`ProgressPlugin`](/plugins/progress-plugin/) will calculate a percentage based on the current hook.
+* `...args`: Any number of strings, which will be passed to the `ProgressPlugin` handler to be reported to the user.
+
+Note that only a subset of compiler and compilation hooks support the `reportProgress` function. See [`ProgressPlugin`](/plugins/progress-plugin/#supported-hooks) for a full list.
 
 ## Next Steps
 

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/hot-module-replacement.md

@@ -2,6 +2,7 @@
 title: Hot Module Replacement
 sort: 11
 contributors:
+  - kryptokinght
   - SpaceK33z
   - sokra
   - GRardB
@@ -13,7 +14,7 @@ Hot Module Replacement (HMR) exchanges, adds, or removes [modules](/concepts/mod
 
 - Retain application state which is lost during a full reload.
 - Save valuable development time by only updating what's changed.
-- Tweak styling faster -- almost comparable to changing styles in the browser's debugger.
+- Modifications made to CSS/JS in the source code results in an instant browser update which is almost comparable to changing styles directly in the browser's dev tools.
 
 
 ## How It Works

src/content/concepts/index.md

@@ -14,22 +14,25 @@ contributors:
   - arjunsajeev
   - byzyk
   - yairhaimo
+  - EugeneHlushko
+  - farskid
 ---
 
-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 +43,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 +60,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 +85,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 and JSON 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 +113,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 +128,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/loaders.md

@@ -10,6 +10,7 @@ contributors:
   - simon04
   - jhnns
   - byzyk
+  - debs-obrien
 ---
 
 Loaders are transformations that are applied on the source code of a module. They allow you to pre-process files as you `import` or “load” them. Thus, loaders are kind of like “tasks” in other build tools and provide a powerful way to handle front-end build steps. Loaders can transform files from a different language (like TypeScript) to JavaScript or inline images as data URLs. Loaders even allow you to do things like `import` CSS files directly from your JavaScript modules!
@@ -121,6 +122,6 @@ functions (loaders). Users now have more flexibility to include fine-grained log
 
 ## Resolving Loaders
 
-Loaders follow the standard [module resolution](/concepts/module-resolution/). In most cases it will be loaders from the [module path](/concepts/module-resolution/#module-paths) (think `npm install`, `node_modules`).
+Loaders follow the standard [module resolution](/concepts/module-resolution/). In most cases it will be loaded from the [module path](/concepts/module-resolution/#module-paths) (think `npm install`, `node_modules`).
 
 A loader module is expected to export a function and be written in Node.js compatible JavaScript. They are most commonly managed with npm, but you can also have custom loaders as files within your application. By convention, loaders are usually named `xxx-loader` (e.g. `json-loader`). See ["How to Write a Loader?"](/development/how-to-write-a-loader) for more information.