您 -> 你 & 统一为：本指南继续沿用[xxx](/guides/xxx)中的代码示例

.github/CONTRIBUTING.md

@@ -30,6 +30,8 @@ See the `package.json` for the full list of `scripts`.
 
 > Note that a __Python version between v2.5.0 and 3.0.0__ is required for the [proselint][12] dependency.
 
+> On Debian and Ubuntu operating systems you may have to use `node >= 7.0.0` to avoid build errors with `node-sass`. Please note that we don't officially support building on these systems.
+
 
 ## Contributor License Agreement
 

src/content/api/index.md

@@ -29,7 +29,7 @@ While most users can get away with just using the CLI along with a configuration
 
 ## Loaders
 
-Loaders are transformations that are applied to the source code of a module. They are written as functions that take accept source code as a parameter and return a new version of that code with tranformations applied.
+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.
 
 [Learn more!](/api/loaders)
 

src/content/concepts/loaders.md

@@ -43,9 +43,9 @@ module.exports = {
 
 There are three ways to use loaders in your application:
 
-* Configuration (recommended): Specify them in your __webpack.config.js__ file.
-* Inline: Specify them explicitly in each `import` statement.
-* CLI: Specify them within a shell command.
+* [Configuration](#configuration) (recommended): Specify them in your __webpack.config.js__ file.
+* [Inline](#inline): Specify them explicitly in each `import` statement.
+* [CLI](#cli): Specify them within a shell command.
 
 
 ### Configuration

src/content/configuration/dev-server.md

@@ -40,7 +40,7 @@ Content not from webpack is served from /path/to/dist/
 
 that will give some background on where the server is located and what it's serving.
 
-If you're using dev-server through the Node.js API, the options in `devServer` will be ignored. Pass the options as a second parameter instead: `new WebpackDevServer(compiler, {...})`. [See here](https://github.com/webpack/webpack-dev-server/blob/master/examples/node-api-simple/server.js) for an example of how to use webpack-dev-server through the Node.js API.
+If you're using dev-server through the Node.js API, the options in `devServer` will be ignored. Pass the options as a second parameter instead: `new WebpackDevServer(compiler, {...})`. [See here](https://github.com/webpack/webpack-dev-server/tree/master/examples/api/simple) for an example of how to use webpack-dev-server through the Node.js API.
 
 W> Be aware that when [exporting multiple configurations](/configuration/configuration-types/#exporting-multiple-configurations) only the `devServer` options for the first configuration will be taken into account and used for all the configurations in the array.
 

src/content/configuration/plugins.md

@@ -29,7 +29,7 @@ plugins: [
 A more complex example, using multiple plugins, might look something like this:
 
 ```js
-var webpack = require('webpack')
+var webpack = require('webpack');
 // importing plugins that do not come by default in webpack
 var ExtractTextPlugin = require('extract-text-webpack-plugin');
 var DashboardPlugin = require('webpack-dashboard/plugin');

src/content/contribute/writing-a-plugin.md

@@ -178,7 +178,7 @@ This is the simplest format for a plugin. Many useful events like `"compile"`, `
 
 `applyPluginsWaterfall(name: string, init: any, args: any...)`
 
-Here each of the plugins are called one after the other with the args from the return value of the previous plugin. The plugin must take into consider the order of its execution.
+Here each of the plugins are called one after the other with the args from the return value of the previous plugin. The plugin must take the order of its execution into account.
 It must accept arguments from the previous plugin that was executed. The value for the first plugin is `init`. This pattern is used in the Tapable instances which are related to the `webpack` templates like `ModuleTemplate`, `ChunkTemplate` etc.
 
 - __asynchronous__ When all the plugins are applied asynchronously using

src/content/guides/build-performance.md

@@ -68,7 +68,7 @@ Use the `DllPlugin` to move code that is changed less often into a separate comp
 
 Decrease the total size of the compilation to increase build performance. Try to keep chunks small.
 
-- Use less/smaller libraries.
+- Use fewer/smaller libraries.
 - Use the `CommonsChunksPlugin` in Multi-Page Applications.
 - Use the `CommonsChunksPlugin` in `async` mode in Multi-Page Applications.
 - Remove unused code.

src/content/guides/getting-started.md

@@ -12,6 +12,7 @@ contributors:
   - jecoopr
   - TheDutchCoder
   - sudarsangp
+  - Vanguard90
 ---
 
 As you may already know, webpack is used to compile JavaScript modules. Once [installed](/guides/installation), you can interface with webpack either from its [CLI](/api/cli) or [API](/api/node). If you're still new to webpack, please read through the [core concepts](/concepts) and [this comparison](/comparison) to learn why you might use it over the other tools that are out in the community.
@@ -140,10 +141,10 @@ __dist/index.html__
 
 In this setup, `index.js` explicitly requires `lodash` to be present, and binds it as `_` (no global scope pollution). By stating what dependencies a module needs, webpack can use this information to build a dependency graph. It then uses the graph to generate an optimized bundle where scripts will be executed in the correct order.
 
-With that said, let's run `webpack` with our script as the [entry point](/concepts/entry-points) and `bundle.js` as the [output](/concepts/output):
+With that said, let's run `npx webpack` with our script as the [entry point](/concepts/entry-points) and `bundle.js` as the [output](/concepts/output). The `npx` command, which ships with Node 8.2 or higher, runs the webpack binary (`./node_modules/.bin/webpack`) of the webpack package we installed in the beginning:
 
 ``` bash
-./node_modules/.bin/webpack src/index.js dist/bundle.js
+npx webpack src/index.js dist/bundle.js
 
 Hash: ff6c1d39b26f89b3b7bb
 Version: webpack 2.2.0
@@ -203,7 +204,7 @@ module.exports = {
 Now, let's run the build again but instead using our new configuration:
 
 ``` bash
-./node_modules/.bin/webpack --config webpack.config.js
+npx webpack --config webpack.config.js
 
 Hash: ff6c1d39b26f89b3b7bb
 Version: webpack 2.2.0
@@ -216,6 +217,8 @@ bundle.js  544 kB       0  [emitted]  [big]  main
    [3] ./src/index.js 278 bytes {0} [built]
 ```
 
+W> Note that when calling `webpack` via its path on windows, you must use backslashes instead, e.g. `node_modules\.bin\webpack --config webpack.config.js`.
+
 T> If a `webpack.config.js` is present, the `webpack` command picks it up by default. We use the `--config` option here only to show that you can pass a config of any name. This will be useful for more complex configurations that need to be split into multiple files.
 
 A configuration file allows far more flexibility than simple CLI usage. We can specify loader rules, plugins, resolve options and many other enhancements this way. See the [configuration documentation](/configuration) to learn more.
@@ -237,7 +240,7 @@ __package.json__
 }
 ```
 
-Now the `npm run build` command can be used in place of the longer commands we used earlier. Note that within `scripts` we can reference locally installed npm packages by name instead of writing out the entire path. This convention is the standard in most npm-based projects and allows us to directly call `webpack`, instead of `./node_modules/.bin/webpack`
+Now the `npm run build` command can be used in place of the `npx` command we used earlier. Note that within `scripts` we can reference locally installed npm packages by name the same way we did with `npx`. This convention is the standard in most npm-based projects because it allows all contributors to use the same set of common scripts (each with flags like `--config` if necessary).
 
 Now run the following command and see if your script alias works:
 

src/content/guides/shimming.md

@@ -90,7 +90,15 @@ What we've essentially done here is tell webpack...
 If we run a build, we should still see the same output:
 
 ``` bash
-TODO: Include output
+Hash: f450fa59fa951c68c416
+Version: webpack 2.2.0
+Time: 343ms
+    Asset    Size  Chunks                    Chunk Names
+bundle.js  544 kB       0  [emitted]  [big]  main
+   [0] ./~/lodash/lodash.js 540 kB {0} [built]
+   [1] (webpack)/buildin/global.js 509 bytes {0} [built]
+   [2] (webpack)/buildin/module.js 517 bytes {0} [built]
+   [3] ./src/index.js 189 bytes {0} [built]
 ```
 
 We can also use the `ProvidePlugin` to expose a single export of a module by configuring it with an "array path" (e.g. `[module, child, ...children?]`). So let's imagine we only wanted to provide the `join` method from `lodash` wherever it's invoked:

src/content/guides/tree-shaking.md

@@ -59,7 +59,7 @@ export function cube(x) {
 }
 ```
 
-With that in place, let's update our entry script to utilize this one of these new methods and remove `lodash` for simplicity:
+With that in place, let's update our entry script to utilize one of these new methods and remove `lodash` for simplicity:
 
 __src/index.js__
 
@@ -185,6 +185,6 @@ So, what we've learned is that in order to take advantage of _tree shaking_, you
 - Use ES2015 module syntax (i.e. `import` and `export`).
 - Include a minifier that supports dead code removal (e.g. the `UglifyJSPlugin`).
 
-You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves of the tree that are consumed by autumn. In order to get rid of the dead leaves, you have to shake the tree, causing them fall.
+You can imagine your application as a tree. The source code and libraries you actually use represent the green, living leaves of the tree. Dead code represents the brown, dead leaves of the tree that are consumed by autumn. In order to get rid of the dead leaves, you have to shake the tree, causing them to fall.
 
 If you are interested in more ways to optimize your output, please jump to the next guide for details on building for [production](/guides/production).

src/content/plugins/commons-chunk-plugin.md

@@ -201,7 +201,7 @@ new webpack.optimize.CommonsChunkPlugin({
   name: "vendor",
   minChunks: function (module) {
     // this assumes your vendor imports exist in the node_modules directory
-    return module.context && module.context.indexOf("node_modules") !== -1;
+    return module.context && module.context.includes("node_modules");
   }
 })
 ```