Merge branch 'next' into plugin-api-rewrite

skipjack · web-flow · commit 766808282532 · 2017-12-17T23:26:09.000-05:00
diff --git a/src/content/api/cli.md b/src/content/api/cli.md
@@ -4,6 +4,7 @@ sort: 2
 contributors:
   - ev1stensberg
   - simon04
+  - tbroadley
 related:
   - title: Analyzing Build Statistics
     url: https://survivejs.com/webpack/optimizing-build/analyzing-build-statistics/
@@ -150,7 +151,7 @@ Parameter                 | Explanation                                 | Input
 `--output-filename`       | The output filename of the bundle           | string     | [name].js
 `--output-jsonp-function` | The name of the JSONP function used for chunk loading | string | webpackJsonp
 `--output-library`        | Expose the exports of the entry point as library | string |
-`--output-library-target` | The type for exposing the exports of the entry,point as library | string | var
+`--output-library-target` | The type for exposing the exports of the entry point as library | string | var
 `--output-path`           | The output path for compilation assets      | string     | Current directory
 `--output-pathinfo`       | Include a comment with the request for every dependency | boolean | false
 `--output-public-path`    | The public path for the assets              | string     | /
@@ -238,7 +239,7 @@ These allow you to configure the webpack [resolver](/configuration/resolve/) wit
 Parameter              | Explanation                                             | Example
 ---------------------- | ------------------------------------------------------- | -------------
 --resolve-alias        | Setup a module alias for resolving                      | --resolve-alias jquery-plugin=jquery.plugin
---resolve-extensions   | Setup extensions that should be used to resolve,modules | --resolve-extensions .es6 .js .ts
+--resolve-extensions   | Setup extensions that should be used to resolve modules | --resolve-extensions .es6 .js .ts
 --resolve-loader-alias | Minimize javascript and switches loaders to minimizing  |
 
 
diff --git a/src/content/api/hot-module-replacement.md b/src/content/api/hot-module-replacement.md
@@ -3,6 +3,7 @@ title: Hot Module Replacement
 contributors:
   - sokra
   - skipjack
+  - tbroadley
 related:
   - title: Concepts - Hot Module Replacement
     url: /concepts/hot-module-replacement
@@ -117,7 +118,7 @@ The optional `options` object can include the following properties:
 
 - `ignoreUnaccepted` (boolean): Ignore changes made to unaccepted modules.
 - `ignoreDeclined` (boolean): Ignore changes made to declined modules.
-- `ignoreErrored` (boolean): Ignore errors throw in accept handlers, error handlers and while reevaulating module.
+- `ignoreErrored` (boolean): Ignore errors throw in accept handlers, error handlers and while reevaluating module.
 - `onDeclined` (function(info)): Notifier for declined modules
 - `onUnaccepted` (function(info)): Notifier for unaccepted modules
 - `onAccepted` (function(info)): Notifier for accepted modules
diff --git a/src/content/api/index.md b/src/content/api/index.md
@@ -1,6 +1,8 @@
 ---
 title: Introduction
 sort: 1
+contributors:
+  - tbroadley
 ---
 
 A variety of interfaces are available to customize the compilation process. Some
@@ -32,7 +34,7 @@ module syntaxes -- specifically the [methods](/api/module-methods) and
 
 While most users can get away with just 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, programatically running
+interface. This includes passing multiple configurations, programmatically running
 or watching, and collecting stats.
 
 [Learn more!](/api/node)
@@ -42,7 +44,7 @@ or watching, and collecting stats.
 
 Loaders are transformations that are applied to the source code of a module. They
 are written as functions that accept source code as a parameter and return a new
-version of that code with tranformations applied.
+version of that code with transformations applied.
 
 [Learn more!](/api/loaders)
 
diff --git a/src/content/api/loaders.md b/src/content/api/loaders.md
@@ -4,6 +4,7 @@ sort: 4
 contributors:
     - TheLarkInn
     - jhnns
+    - tbroadley
 ---
 
 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.
@@ -210,7 +211,7 @@ this.callback(
 
 T> It can be useful to pass an abstract syntax tree (AST), like [`ESTree`](https://github.com/estree/estree), as the fourth argument (`meta`) to speed up the build time if you want to share common ASTs between loaders.
 
-In case this function is called, you should return undefined to avoid ambigious loader results.
+In case this function is called, you should return undefined to avoid ambiguous loader results.
 
 
 ### `this.async`
@@ -391,7 +392,7 @@ Access to the `compilation`'s `inputFileSystem` property.
 
 ## Deprecated context properties
 
-W> The usage of these properties is highly discouraged since we are planing to remove them from the context. They are still listed here for documentation purposes.
+W> The usage of these properties is highly discouraged since we are planning to remove them from the context. They are still listed here for documentation purposes.
 
 
 ### `this.exec`
diff --git a/src/content/api/module-variables.md b/src/content/api/module-variables.md
@@ -6,6 +6,7 @@ contributors:
   - skipjack
   - sokra
   - ahmehri
+  - tbroadley
 related:
   - title: CommonJS
     url: https://en.wikipedia.org/wiki/CommonJS
@@ -50,7 +51,7 @@ W> This CANNOT be used in an asynchronous function.
 
 ### `exports` (CommonJS)
 
-This variable is equal ot default value of `module.exports` (i.e. an object). If `module.exports` gets overwritten, `exports` will no longer be exported.
+This variable is equal to default value of `module.exports` (i.e. an object). If `module.exports` gets overwritten, `exports` will no longer be exported.
 
 ``` javascript
 exports.someValue = 42;
diff --git a/src/content/configuration/performance.md b/src/content/configuration/performance.md
@@ -3,6 +3,7 @@ title: Performance
 sort: 14
 contributors:
   - thelarkinn
+  - tbroadley
 ---
 
 These options allows you to control how webpack notifies you of assets and entrypoints that exceed a specific file limit. 
@@ -12,7 +13,7 @@ This feature was inspired by the idea of [webpack Performance Budgets](https://g
 
 `object`
 
-Configure how performance hints are shown. For example if you have an asset that is over 250kb, webpack will emit a warning notifiying you of this.
+Configure how performance hints are shown. For example if you have an asset that is over 250kb, webpack will emit a warning notifying you of this.
 
 
 ## `performance.hints`
diff --git a/src/content/configuration/resolve.md b/src/content/configuration/resolve.md
@@ -7,6 +7,7 @@ contributors:
   - SpaceK33z
   - pksjce
   - sebastiandeutsch
+  - tbroadley
 ---
 
 These options change how modules are resolved. webpack provides reasonable defaults, but it is possible to change the resolving in detail. Have a look at [Module Resolution](/concepts/module-resolution) for more explanation of how the resolver works.
@@ -216,7 +217,7 @@ With an absolute path, it will only search in the given directory.
 modules: ["node_modules"]
 ```
 
-If you want to add a directory to search in that takes precedences over `node_modules/`:
+If you want to add a directory to search in that takes precedence over `node_modules/`:
 
 ``` js
 modules: [path.resolve(__dirname, "src"), "node_modules"]
diff --git a/src/content/configuration/target.md b/src/content/configuration/target.md
@@ -7,6 +7,7 @@ contributors:
   - skipjack
   - SpaceK33z
   - pastelsky
+  - tbroadley
 ---
 
 webpack can compile for multiple environments or _targets_. To understand what a `target` is in detail, read through [the targets concept page](/concepts/targets).
@@ -15,7 +16,7 @@ webpack can compile for multiple environments or _targets_. To understand what a
 
 `string | function(compiler)`
 
-Intructs webpack to target a specific environment.
+Instructs webpack to target a specific environment.
 
 
 ### `string`
diff --git a/src/content/contribute/debugging.md b/src/content/contribute/debugging.md
@@ -3,6 +3,7 @@ title: Debugging
 sort: 7
 contributors:
   - skipjack
+  - tbroadley
 related:
   - title: Learn and Debug webpack with Chrome DevTools!
     url: https://medium.com/webpack/webpack-bits-learn-and-debug-webpack-with-chrome-dev-tools-da1c5b19554b
@@ -36,7 +37,7 @@ On top of that, the official [analyze tool](https://github.com/webpack/analyse)
 
 While [`console`](https://nodejs.org/api/console.html) statements may work well in simpler scenarios, sometimes a more robust solution is needed. As most front-end developers already know, Chrome DevTools are a life saver when debugging web applications, _but they don’t have to stop there_. As of Node v6.3.0+, developers can use the built-in `--inspect` flag to debug a node program in DevTools.
 
-This gives you the power to easily create breakpoints, debug memory usage, expose and examine objects in the console, and much more. In this short demo, we'll utilize the [`node-nightly`](https://github.com/hemanth/node-nightly) package which provides access to the latest and greatest inpecting capabilites.
+This gives you the power to easily create breakpoints, debug memory usage, expose and examine objects in the console, and much more. In this short demo, we'll utilize the [`node-nightly`](https://github.com/hemanth/node-nightly) package which provides access to the latest and greatest inspecting capabilities.
 
 W> The `--inspect` interface has been available since v6.3.0 so feel to try it out with your local version, but be warned that certain features and flags may differ from the ones in this demo.
 
diff --git a/src/content/contribute/index.md b/src/content/contribute/index.md
@@ -6,6 +6,7 @@ contributors:
   - scottdj92
   - harrynewsome
   - dhedgecock
+  - tbroadley
 ---
 
 The people who contribute to webpack do so for the love of open source, our users and ecosystem, and most importantly, pushing the web forward together. Because of our [Open Collective](http://opencollective.com/webpack) model for funding and transparency, we are able to funnel support and funds through contributors, dependent projects, and the contributor and core teams. To make a donation, simply click the button below...
@@ -34,7 +35,7 @@ Anybody can help by doing any of the following:
 
 ### Encouraging Employers
 
-You can ask your employer to improve your workflow by leveraging webpack: an all-in-one tool for fonts, images and image optimiziation, and json. Explain to them how webpack will attempt to bundle your code and assets the best it can for the smallest file size, leading to speedier sites and applications.
+You can ask your employer to improve your workflow by leveraging webpack: an all-in-one tool for fonts, images and image optimization, and json. Explain to them how webpack will attempt to bundle your code and assets the best it can for the smallest file size, leading to speedier sites and applications.
 
 ### Your Contributions
 
diff --git a/src/content/contribute/writing-a-loader.md b/src/content/contribute/writing-a-loader.md
@@ -127,10 +127,10 @@ import { getOptions } from 'loader-utils';
 import validateOptions from 'schema-utils';
 
 const schema = {
-  type: object,
+  type: 'object',
   properties: {
     test: {
-      type: string
+      type: 'string'
     }
   }
 }
@@ -209,7 +209,7 @@ For instance, the `sass-loader` [specifies `node-sass`](https://github.com/webpa
 So you've written a loader, followed the guidelines above, and have it set up to run locally. What's next? Let's go through a simple unit testing example to ensure our loader is working the way we expect. We'll be using the [Jest](https://facebook.github.io/jest/) framework to do this. We'll also install `babel-jest` and some presets that will allow us to use the `import` / `export` and `async` / `await`. Let's start by installing and saving these as a `devDependencies`:
 
 ``` bash
-npm i --save-dev jest babel-jest babel-preset-env
+npm install --save-dev jest babel-jest babel-preset-env
 ```
 
 __.babelrc__
@@ -254,7 +254,7 @@ Hey [name]!
 Pay close attention to this next step as we'll be using the [Node.js API](/api/node) and [`memory-fs`](https://github.com/webpack/memory-fs) to execute webpack. This lets us avoid emitting `output` to disk and will give us access to the `stats` data which we can use to grab our transformed module:
 
 ``` bash
-npm i --save-dev webpack memory-fs
+npm install --save-dev webpack memory-fs
 ```
 
 __test/compiler.js__
diff --git a/src/content/contribute/writing-a-plugin.md b/src/content/contribute/writing-a-plugin.md
@@ -1,6 +1,8 @@
 ---
 title: Writing a Plugin
 sort: 4
+contributors:
+  - tbroadley
 ---
 
 Plugins expose the full potential of the webpack engine to third-party developers. Using staged build callbacks, developers can introduce their own behaviors into the webpack build process. Building plugins is a bit more advanced than building loaders, because you'll need to understand some of the webpack low-level internals to hook into them. Be prepared to read some source code!
@@ -185,7 +187,7 @@ It must accept arguments from the previous plugin that was executed. The value f
 
 `applyPluginsAsync(name: string, args: any..., callback: (err?: Error) -> void)`
 
-The plugin handler functions are called with all args and a callback function with the signature `(err?: Error) -> void`. The handler functions are called in order of registration.`callback` is called after all the handlers are called.
+The plugin handler functions are called with all args and a callback function with the signature `(err?: Error) -> void`. The handler functions are called in order of registration. `callback`` is called after all the handlers are called.
 This is also a commonly used pattern for events like `"emit"`, `"run"`.
 
 - __async waterfall__ The plugins will be applied asynchronously in the waterfall manner.
diff --git a/src/content/guides/build-performance.md b/src/content/guides/build-performance.md
@@ -3,6 +3,7 @@ title: Build Performance
 sort: 17
 contributors:
   - sokra
+  - tbroadley
 ---
 
 This guide contains some useful tips for improving build/compilation performance.
@@ -61,7 +62,7 @@ The following steps can increase the speed of resolving:
 
 ### Dlls
 
-Use the `DllPlugin` to move code that is changed less often into a separate compilation. This will improve the application's compilation speed, although it does increase complexitity of the build process.
+Use the `DllPlugin` to move code that is changed less often into a separate compilation. This will improve the application's compilation speed, although it does increase complexity of the build process.
 
 
 ### Smaller = Faster
@@ -72,7 +73,7 @@ Decrease the total size of the compilation to increase build performance. Try to
 - Use the `CommonsChunksPlugin` in Multi-Page Applications.
 - Use the `CommonsChunksPlugin` in `async` mode in Multi-Page Applications.
 - Remove unused code.
-- Only compile the part of the code you are currenly developing on.
+- Only compile the part of the code you are currently developing on.
 
 
 ### Worker Pool
@@ -89,7 +90,7 @@ Enable persistent caching with the `cache-loader`. Clear cache directory on `"po
 
 ### Custom plugins/loaders
 
-Profile them to not intruduce a performance problem here.
+Profile them to not introduce a performance problem here.
 
 ---
 
@@ -119,7 +120,7 @@ The following utilities improve performance by compiling and serving assets in m
 
 Be aware of the performance differences of the different `devtool` settings.
 
-- `"eval"` has the best performance, but doesn't assist you for transpilied code.
+- `"eval"` has the best performance, but doesn't assist you for transpiled code.
 - The `cheap-source-map` variants are more performant, if you can live with the slightly worse mapping quality.
 - Use a `eval-source-map` variant for incremental builds.
 
diff --git a/src/content/guides/environment-variables.md b/src/content/guides/environment-variables.md
@@ -4,14 +4,15 @@ sort: 16
 contributors:
   - simon04
   - grisanu
+  - tbroadley
 related:
   - title: The Fine Art of the webpack 3 Config
     url: https://blog.flennik.com/the-fine-art-of-the-webpack-2-config-dc4d19d7f172#d60a
 ---
 
 To disambiguate in your `webpack.config.js` between [development](/guides/development) and [production builds](/guides/production), you may use environment variables.
 
-The webpack command line [environment option](/api/cli/#environment-options), `--env` allows you to pass in as many environment variables as you like. Environment variables will be made accesible in your `webpack.config.js`. For example, `--env.production` or `--env.NODE_ENV=local` (`NODE_ENV` is conventionally used to define the environment type, see [here](https://dzone.com/articles/what-you-should-know-about-node-env).)
+The webpack command line [environment option](/api/cli/#environment-options), `--env` allows you to pass in as many environment variables as you like. Environment variables will be made accessible in your `webpack.config.js`. For example, `--env.production` or `--env.NODE_ENV=local` (`NODE_ENV` is conventionally used to define the environment type, see [here](https://dzone.com/articles/what-you-should-know-about-node-env).)
 
 ```bash
 webpack --env.NODE_ENV=local --env.production --progress
diff --git a/src/content/guides/integrations.md b/src/content/guides/integrations.md
@@ -27,7 +27,7 @@ So while webpack's core focus is bundling, there are a variety of extensions tha
 For those using Grunt, we recommend the [`grunt-webpack`](https://www.npmjs.com/package/grunt-webpack) package. With `grunt-webpack` you can run webpack or [webpack-dev-server](https://github.com/webpack/webpack-dev-server) as a task, get access to stats within [template tags](https://gruntjs.com/api/grunt.template), split development and production configurations and more. Start by installing `grunt-webpack` as well as `webpack` itself if you haven't already:
 
 ``` bash
-npm i --save-dev grunt-webpack webpack
+npm install --save-dev grunt-webpack webpack
 ```
 
 Then register a configuration and load the task:
@@ -60,7 +60,7 @@ For more information, please visit the [repository](https://github.com/webpack-c
 Gulp is also a fairly straightforward integration with the help of the [`webpack-stream`](https://github.com/shama/webpack-stream) package (a.k.a. `gulp-webpack`). In this case, it is unnecessary to install `webpack` separately as it is a direct dependency of `webpack-stream`:
 
 ``` bash
-npm i --save-dev webpack-stream
+npm install --save-dev webpack-stream
 ```
 
 Just `require('webpack-stream')` instead of `webpack` and optionally pass it an configuration:
@@ -87,7 +87,7 @@ For more information, please visit the [repository](https://github.com/shama/web
 The [`mocha-webpack`](https://github.com/zinserjan/mocha-webpack) utility can be used for a clean integration with Mocha. The repository offers more details on the pros and cons but essentially `mocha-webpack` is a simple wrapper that provides almost the same CLI as Mocha itself and provides various webpack functionality like an improved watch mode and improved path resolution. Here is a small example of how you would install it and use it to run a test suite (found within `./test`):
 
 ``` bash
-npm i --save-dev webpack mocha mocha-webpack
+npm install --save-dev webpack mocha mocha-webpack
 mocha-webpack 'test/**/*.js'
 ```
 
@@ -99,7 +99,7 @@ For more information, please visit the [repository](https://github.com/zinserjan
 The [`karma-webpack`](https://github.com/webpack-contrib/karma-webpack) package allows you to use webpack to pre-process files in [Karma](http://karma-runner.github.io/1.0/index.html). It also makes use of [`webpack-dev-middleware`](https://github.com/webpack/webpack-dev-middleware) and allows passing configurations for both. A simple example may look something like this:
 
 ``` bash
-npm i --save-dev webpack karma karma-webpack
+npm install --save-dev webpack karma karma-webpack
 ```
 
 __karma.conf.js__
diff --git a/src/content/guides/output-management.md b/src/content/guides/output-management.md
@@ -5,6 +5,7 @@ contributors:
   - skipjack
   - TheDutchCoder
   - sudarsangp
+  - JGJP
 ---
 
 T> This guide extends on code examples found in the [`Asset Management`](/guides/asset-management) guide.
@@ -89,11 +90,11 @@ __webpack.config.js__
   const path = require('path');
 
   module.exports = {
-    entry: {
--     index: './src/index.js',
+-   entry: './src/index.js',
++   entry: {
 +     app: './src/index.js',
 +     print: './src/print.js'
-    },
++   },
     output: {
 -     filename: 'bundle.js',
 +     filename: '[name].bundle.js',
diff --git a/src/content/guides/shimming.md b/src/content/guides/shimming.md
diff --git a/src/content/guides/tree-shaking.md b/src/content/guides/tree-shaking.md
diff --git a/src/content/plugins/limit-chunk-count-plugin.md b/src/content/plugins/limit-chunk-count-plugin.md
