Merge pull request #10591 from wizardofhogwarts/patch-11

docs: Grammatical fixes in examples

examples/extra-async-chunk/README.md

@@ -1,4 +1,4 @@
-This example shows automatically created async commons chunks.
+This example shows the automatically created async commons chunks.
 
 The example entry references two chunks:
 
@@ -16,7 +16,7 @@ The example entry references two chunks:
 
 These chunks share modules `a` and `b`. The optimization extract these into chunk Z:
 
-Note: Actually the optimization compare size of chunk Z to some minimum value, but this is disabled from this example. In practice there is no configuration needed for this.
+Note: The optimization compares the size of chunk Z to some minimum value, but this is disabled from this example. In practice, there is no configuration needed for this.
 
 - entry chunk
   - async require -> chunk X & Z

examples/extra-async-chunk/template.md

@@ -1,4 +1,4 @@
-This example shows automatically created async commons chunks.
+This example shows the automatically created async commons chunks.
 
 The example entry references two chunks:
 
@@ -16,7 +16,7 @@ The example entry references two chunks:
 
 These chunks share modules `a` and `b`. The optimization extract these into chunk Z:
 
-Note: Actually the optimization compare size of chunk Z to some minimum value, but this is disabled from this example. In practice there is no configuration needed for this.
+Note: The optimization compares the size of chunk Z to some minimum value, but this is disabled from this example. In practice, there is no configuration needed for this.
 
 - entry chunk
   - async require -> chunk X & Z

examples/harmony-interop/example.js

@@ -1,6 +1,6 @@
 // harmony module
 
-// import from CommonJs module
+// import from CommonJS module
 import fs from "./fs";
 import { readFile } from "./fs";
 import * as fs2 from "./fs";

examples/harmony-unused/README.md

@@ -1,10 +1,10 @@
-This example demonstrates how webpack tracks the using of ES6 imports and exports. Only used exports are emitted to the resulting bundle. The minimizing step then removes the declarations because they are unused.
+This example demonstrates how webpack tracks the usage of ES6 imports and exports. Only used exports are emitted to the resulting bundle. The minimizing step then removes the declarations because they are unused.
 
 Excluding unused exports from bundles is known as "[tree-shaking](http://www.2ality.com/2015/12/webpack-tree-shaking.html)".
 
 In this example, only `add` and `multiply` in `./math.js` are used by the app. `list` is unused and is not included in the minimized bundle (Look for `Array.from` in the minimized bundle).
 
-In addition to that, `library.js` simulates an entry point to a big library. `library.js` re-exports multiple identifiers from submodules. Often big parts of that is unused, like `abc.js`. Note how the usage information flows from `example.js` through `library.js` into `abc.js` and all declarations in `abc.js` are not included in the minimized bundle (Look for `console.log("a")` in the minimized bundle).
+In addition to that, `library.js` simulates an entry point to a big library. `library.js` re-exports multiple identifiers from submodules. Often big parts of that are unused, like `abc.js`. Note how the usage information flows from `example.js` through `library.js` into `abc.js` and all declarations in `abc.js` are not included in the minimized bundle (Look for `console.log("a")` in the minimized bundle).
 
 # example.js
 

examples/harmony-unused/template.md

@@ -1,10 +1,10 @@
-This example demonstrates how webpack tracks the using of ES6 imports and exports. Only used exports are emitted to the resulting bundle. The minimizing step then removes the declarations because they are unused.
+This example demonstrates how webpack tracks the usage of ES6 imports and exports. Only used exports are emitted to the resulting bundle. The minimizing step then removes the declarations because they are unused.
 
 Excluding unused exports from bundles is known as "[tree-shaking](http://www.2ality.com/2015/12/webpack-tree-shaking.html)".
 
 In this example, only `add` and `multiply` in `./math.js` are used by the app. `list` is unused and is not included in the minimized bundle (Look for `Array.from` in the minimized bundle).
 
-In addition to that, `library.js` simulates an entry point to a big library. `library.js` re-exports multiple identifiers from submodules. Often big parts of that is unused, like `abc.js`. Note how the usage information flows from `example.js` through `library.js` into `abc.js` and all declarations in `abc.js` are not included in the minimized bundle (Look for `console.log("a")` in the minimized bundle).
+In addition to that, `library.js` simulates an entry point to a big library. `library.js` re-exports multiple identifiers from submodules. Often big parts of that are unused, like `abc.js`. Note how the usage information flows from `example.js` through `library.js` into `abc.js` and all declarations in `abc.js` are not included in the minimized bundle (Look for `console.log("a")` in the minimized bundle).
 
 # example.js
 

examples/http2-aggressive-splitting/README.md

@@ -1,12 +1,12 @@
-This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with a HTTP2 web server, otherwise there is an overhead for the increased number of requests.
+This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with an HTTP2 web server, otherwise, there is an overhead for the increased number of requests.
 
-AggressiveSplittingPlugin splits every chunk until it reaches the specified `maxSize`. In this example it tries to create chunks with <50kB raw code, which typically minimizes to ~10kB. It groups modules together by folder structure, because modules in the same folder are likely to have similar repetitive text, making them gzip efficiently together. They are also likely to change together.
+AggressiveSplittingPlugin splits every chunk until it reaches the specified `maxSize`. In this example, it tries to create chunks with <50kB raw code, which typically minimizes to ~10kB. It groups modules by folder structure because modules in the same folder are likely to have similar repetitive text, making them gzip efficiently together. They are also likely to change together.
 
 AggressiveSplittingPlugin records its splitting in the webpack records. When it is next run, it tries to use the last recorded splitting. Since changes to application code between one run and the next are usually in only a few modules (or just one), re-using the old splittings (and chunks, which are probably still in the client's cache), is highly advantageous.
 
-Only chunks which are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating many records of small chunks for every change.
+Only chunks that are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating many records of small chunks for every change.
 
-If a module changes, its chunks are declared to be invalid, and are put back into the module pool. New chunks are created from all modules in the pool.
+If a module changes, its chunks are declared to be invalid and are put back into the module pool. New chunks are created from all modules in the pool.
 
 There is a tradeoff here:
 
@@ -14,7 +14,7 @@ The caching improves with smaller `maxSize`, as chunks change less often and can
 
 The compression improves with bigger `maxSize`, as gzip works better for bigger files. It's more likely to find duplicate strings, etc.
 
-The backward compatibility (non HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases.
+The backward compatibility (non-HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases.
 
 ```js
 var path = require("path");

examples/http2-aggressive-splitting/template.md

@@ -1,12 +1,12 @@
-This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with a HTTP2 web server, otherwise there is an overhead for the increased number of requests.
+This example demonstrates the AggressiveSplittingPlugin for splitting the bundle into multiple smaller chunks to improve caching. This works best with an HTTP2 web server, otherwise, there is an overhead for the increased number of requests.
 
-AggressiveSplittingPlugin splits every chunk until it reaches the specified `maxSize`. In this example it tries to create chunks with <50kB raw code, which typically minimizes to ~10kB. It groups modules together by folder structure, because modules in the same folder are likely to have similar repetitive text, making them gzip efficiently together. They are also likely to change together.
+AggressiveSplittingPlugin splits every chunk until it reaches the specified `maxSize`. In this example, it tries to create chunks with <50kB raw code, which typically minimizes to ~10kB. It groups modules by folder structure, because modules in the same folder are likely to have similar repetitive text, making them gzip efficiently together. They are also likely to change together.
 
 AggressiveSplittingPlugin records its splitting in the webpack records. When it is next run, it tries to use the last recorded splitting. Since changes to application code between one run and the next are usually in only a few modules (or just one), re-using the old splittings (and chunks, which are probably still in the client's cache), is highly advantageous.
 
-Only chunks which are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating many records of small chunks for every change.
+Only chunks that are bigger than the specified `minSize` are stored into the records. This ensures that these chunks fill up as your application grows, instead of creating many records of small chunks for every change.
 
-If a module changes, its chunks are declared to be invalid, and are put back into the module pool. New chunks are created from all modules in the pool.
+If a module changes, its chunks are declared to be invalid and are put back into the module pool. New chunks are created from all modules in the pool.
 
 There is a tradeoff here:
 
@@ -14,7 +14,7 @@ The caching improves with smaller `maxSize`, as chunks change less often and can
 
 The compression improves with bigger `maxSize`, as gzip works better for bigger files. It's more likely to find duplicate strings, etc.
 
-The backward compatibility (non HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases.
+The backward compatibility (non-HTTP2 client) improves with bigger `maxSize`, as the number of requests decreases.
 
 ```js
 _{{webpack.config.js}}_