Merge branch 'master' into rebuild

Author: montogeek

src/content/api/cli.md

@@ -6,6 +6,7 @@ contributors:
   - simon04
   - tbroadley
   - chenxsan
+  - rencire
   - madhavarshney
 related:
   - title: Analyzing Build Statistics
@@ -68,7 +69,7 @@ If your project structure is as follows -
 ```
 
 ```bash
-webpack ./src/index.js dist/bundle.js
+webpack src/index.js -o dist/bundle.js
 ```
 
 This will bundle your source code with entry as `index.js` and the output bundle file will have a path of `dist` and the filename will be `bundle.js`

src/content/api/compiler-hooks.md

@@ -191,13 +191,6 @@ Can return true/false at this point
 Parameters: `compilation`
 
 
-### `needAdditionalPass`
-
-`SyncBailHook`
-
-...
-
-
 ### `emit`
 
 `AsyncSeriesHook`

src/content/api/module-methods.md

@@ -5,6 +5,7 @@ sort: 3
 contributors:
   - skipjack
   - sokra
+  - fadysamirsadek
   - byzyk
 related:
   - title: CommonJS Wikipedia
@@ -74,14 +75,14 @@ W> This feature relies on [`Promise`](https://developer.mozilla.org/en-US/docs/W
 The spec for `import` doesn't allow control over the chunk's name or other properties as "chunks" are only a concept within webpack. Luckily webpack allows some special parameters via comments so as to not break the spec:
 
 ``` js
-// single target
+// Single target
 import(
   /* webpackChunkName: "my-chunk-name" */
   /* webpackMode: "lazy" */
   'module'
 );
 
-// multiple possible targets
+// Multiple possible targets
 import(
   /* webpackInclude: /\.json$/ */
   /* webpackExclude: /\.noimport\.json$/ */
@@ -91,6 +92,14 @@ import(
 );
 ```
 
+```js
+import(/* webpackIgnore: true */ 'ignored-module.js');
+```
+
+`webpackIgnore`: Disables dynamic import parsing when set to `true`.
+
+W> Note that setting `webpackIgnore` to `true` opts out of code splitting.
+
 `webpackChunkName`: A name for the new chunk. Since webpack 2.6.0, the placeholders `[index]` and `[request]` are supported within the given string to an incremented number or the actual resolved filename respectively.
 
 `webpackMode`: Since webpack 2.6.0, different modes for resolving dynamic imports can be specified. The following options are supported:

src/content/concepts/entry-points.md

@@ -34,7 +34,7 @@ module.exports = {
 
 T> **What happens when you pass an array to `entry`?** Passing an array of file paths to the `entry` property creates what is known as a **"multi-main entry"**. This is useful when you would like to inject multiple dependent files together and graph their dependencies into one "chunk".
 
-This is a great choice when you are looking to quickly setup a webpack configuration for an application or tool with one entry point (IE: a library). However, there is not much flexibility in extending or scaling your configuration with this syntax.
+This is a great choice when you are looking to quickly setup a webpack configuration for an application or tool with one entry point (i.e., a library). However, there is not much flexibility in extending or scaling your configuration with this syntax.
 
 
 ## Object Syntax
@@ -75,7 +75,7 @@ module.exports = {
 };
 ```
 
-**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).
+**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).
 

src/content/concepts/index.md

@@ -40,7 +40,7 @@ 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*. 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:
 
@@ -57,7 +57,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,7 +82,7 @@ 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 converting 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.
 
@@ -119,7 +119,7 @@ You can check further customization when including loaders in the [loaders secti
 
 ## Plugins
 
-While loaders are used to transform certain types of modules, plugins can be leveraged to perform a wider range of tasks like bundle optimization, assets management and injection of environment variables.
+While loaders are used to transform certain types of modules, plugins can be leveraged to perform a wider range of tasks like bundle optimization, asset management and injection of environment variables.
 
 T> Check out the [plugin interface](/api/plugins) and how to use it to extend webpacks capabilities.
 
@@ -143,11 +143,11 @@ module.exports = {
 };
 ```
 
-In the example above, the `html-webpack-plugin` generates an html file for your application injecting automatically all your generated bundles.
+In the example above, the `html-webpack-plugin` generates an HTML file for your application by injecting automatically all your generated bundles.
 
 T> There are many plugins that webpack provides out of the box! Check out the [list of plugins](/plugins).
 
-Using plugins in your webpack config is straightforward - however, there are many use cases that are worth further exploration, [learn more about them here](/concepts/plugins).
+Using plugins in your webpack config is straightforward - however, there are many use cases that are worth further exploration. [Learn more about them here](/concepts/plugins).
 
 
 ## Mode

src/content/concepts/loaders.md

@@ -12,7 +12,7 @@ contributors:
   - byzyk
 ---
 
-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!
+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!
 
 
 ## Example
@@ -52,7 +52,9 @@ There are three ways to use loaders in your application:
 ### Configuration
 
 [`module.rules`](/configuration/module/#module-rules) allows you to specify several loaders within your webpack configuration.
-This is a concise way to display loaders, and helps to maintain clean code. It also offers you a full overview of each respective loader:
+This is a concise way to display loaders, and helps to maintain clean code. It also offers you a full overview of each respective loader. 
+
+Loaders are evaluated/executed from right to left. In the example below execution starts with sass-loader, continues with css-loader and finally ends with style-loader. See ["Loader Features"](/concepts/loaders/#loader-features) for more information about loaders order.
 
 ```js-with-links-with-details
 module.exports = {
@@ -67,7 +69,8 @@ module.exports = {
             options: {
               modules: true
             }
-          }
+          },
+          { loader: ['sass-loader'](/loaders/sass-loader) }
         ]
       }
     ]

src/content/concepts/mode.md

@@ -88,7 +88,7 @@ module.exports = {
 }
 ```
 
-If you want to change the behavior according the **mode** variable inside the *webpack.config.js* you have to export a function instead of an object:
+If you want to change the behavior according to the **mode** variable inside the *webpack.config.js*, you have to export a function instead of an object:
 
 ```javascript
 var config = {

src/content/concepts/output.md

@@ -13,23 +13,21 @@ Configuring the `output` configuration options tells webpack how to write the co
 
 ## Usage
 
-The minimum requirements for the `output` property in your webpack config is to set its value to an object including the following two things:
+The minimum requirements for the `output` property in your webpack config is to set its value to an object including the following thing:
 
 - A `filename` to use for the output file(s).
-- An absolute `path` to your preferred output directory.
 
 **webpack.config.js**
 
 ```javascript
 module.exports = {
   output: {
     filename: 'bundle.js',
-    path: '/home/proj/public/assets'
   }
 };
 ```
 
-This configuration would output a single `bundle.js` file into the `/home/proj/public/assets` directory.
+This configuration would output a single `bundle.js` file into the `dist` directory.
 
 
 ## Multiple Entry Points

src/content/concepts/plugins.md

@@ -6,6 +6,7 @@ contributors:
   - jhnns
   - rouzbeh84
   - johnstew
+  - MisterDev
   - byzyk
 ---
 
@@ -32,7 +33,7 @@ class ConsoleLogOnBuildWebpackPlugin {
 }
 ```
 
-First parameter of the tap method of the compiler hook should be a camelized version of the plugin name. It is advisable to use a constant for this so it can be reused in all hooks.
+The first parameter of the tap method of the compiler hook should be a camelized version of the plugin name. It is advisable to use a constant for this so it can be reused in all hooks.
 
 ## Usage
 
@@ -65,6 +66,7 @@ module.exports = {
     ]
   },
   plugins: [
+    new webpack.ProgressPlugin(),
     new HtmlWebpackPlugin({template: './src/index.html'})
   ]
 };
@@ -73,7 +75,7 @@ module.exports = {
 
 ### Node API
 
-?> Even when using the Node API, users should pass plugins via the `plugins` property in the configuration. Using `compiler.apply` should not be the recommended way.
+When using the Node API, you can also pass plugins via the `plugins` property in the configuration.
 
 __some-node-script.js__
 
@@ -82,7 +84,8 @@ const webpack = require('webpack'); //to access webpack runtime
 const configuration = require('./webpack.config.js');
 
 let compiler = webpack(configuration);
-compiler.apply(new webpack.ProgressPlugin());
+
+new webpack.ProgressPlugin().apply(compiler);
 
 compiler.run(function(err, stats) {
   // ...

src/content/configuration/configuration-types.md

@@ -6,6 +6,7 @@ contributors:
   - skipjack
   - kbariotis
   - simon04
+  - fadysamirsadek
   - byzyk
 ---
 
@@ -65,14 +66,18 @@ module.exports = [{
     filename: './dist-amd.js',
     libraryTarget: 'amd'
   },
+  name: 'amd',
   entry: './app.js',
   mode: 'production',
 }, {
   output: {
     filename: './dist-commonjs.js',
     libraryTarget: 'commonjs'
   },
+  name: 'commonjs',
   entry: './app.js',
   mode: 'production',
 }];
 ```
+
+T> If you pass a name to `--config-name` flag, webpack will only build that specific configuration.

src/content/configuration/optimization.md

@@ -39,7 +39,7 @@ T> Learn how [mode](/concepts/mode/) works.
 
 ## `optimization.minimizer`
 
-`UglifyjsWebpackPlugin | [UglifyjsWebpackPlugin]`
+`[UglifyjsWebpackPlugin]`
 
 Allows you to override the default minimizer by providing a different one or more customized [UglifyjsWebpackPlugin](/plugins/uglifyjs-webpack-plugin/) instances.
 
@@ -69,11 +69,35 @@ By default webpack v4+ provides new common chunks strategies out of the box for
 
 `object` `string` `boolean`
 
-Setting `optimization.runtimeChunk` to `true` adds an additional chunk to each entry point containing only the runtime.
-It is possible to use preset mode of the plugin by providing a string value:
+Setting `optimization.runtimeChunk` to `true` or `"multiple"` adds an additional chunk to each entrypoint containing only the runtime. This setting is an alias for:
 
-- `single`: creates a runtime file to be shared for all generated chunks.
-- `multiple`: creates multiple runtime files for common chunks.
+__webpack.config.js__
+
+```js
+module.exports = {
+  //...
+  optimization: {
+    runtimeChunk: {
+      name: entrypoint => `runtime~${entrypoint.name}`
+    }
+  }
+};
+```
+
+The value `"single"` instead creates a runtime file to be shared for all generated chunks. This setting is an alias for:
+
+__webpack.config.js__
+
+```js
+module.exports = {
+  //...
+  optimization: {
+    runtimeChunk: {
+      name: 'runtime'
+    }
+  }
+};
+```
 
 By setting `optimization.runtimeChunk` to `object` it is only possible to provide the `name` property which stands for the name or name factory for the runtime chunks.
 
@@ -135,7 +159,7 @@ module.exports = {
 
 `boolean: false`
 
-Tells webpack to use readable chunk identifiers for better debugging. This option is enabled by default for [mode](/concepts/mode/) `development` and disabled for [mode](/concepts/mode/) `production` if no option is provided in webpack config. 
+Tells webpack to use readable chunk identifiers for better debugging. This option is enabled by default for [mode](/concepts/mode/) `development` and disabled for [mode](/concepts/mode/) `production` if no option is provided in webpack config.
 
 __webpack.config.js__
 
@@ -324,4 +348,37 @@ module.exports = {
     concatenateModules: true
   }
 };
-```
+```
+
+## `optimization.sideEffects`
+
+`bool`
+
+Tells webpack to recognise the [`sideEffects`](https://github.com/webpack/webpack/blob/master/examples/side-effects/README.md) flag in `package.json` or rules to skip over modules which are flagged to contain no side effects when exports are not used. 
+
+__package.json__
+
+``` json
+{
+  "name": "awesome npm module",
+  "version": "1.0.0",
+  "sideEffects": false
+}
+```
+
+T> Please note that `sideEffects` should be in the npm module's `package.json` file and doesn't mean that you need to set `sideEffects` to `false` in your own project's `package.json` which requires that big module.
+
+`optimization.sideEffects` depends on [`optimization.providedExports`](#optimization-providedexports) to be enabled. This dependency has a build time cost, but eliminating modules has positive impact on performance because of less code generation. Effect of this optimization depends on your codebase, try it for possible performance wins.
+
+By default `optimization.sideEffects` is enabled in `production` [mode](/concepts/mode/) and disabled elsewise. 
+
+__webpack.config.js__
+
+```js
+module.exports = {
+  //...
+  optimization: {
+    sideEffects: true
+  }
+};
+```