diff --git a/examples/extra-async-chunk/README.md b/examples/extra-async-chunk/README.md index 2dddd72f6..f806ea210 100644 --- a/examples/extra-async-chunk/README.md +++ b/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 diff --git a/examples/extra-async-chunk/template.md b/examples/extra-async-chunk/template.md index 224d0e404..797ab5cad 100644 --- a/examples/extra-async-chunk/template.md +++ b/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 diff --git a/examples/harmony-interop/example.js b/examples/harmony-interop/example.js index 9061a3f17..5a470e0f5 100644 --- a/examples/harmony-interop/example.js +++ b/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"; diff --git a/examples/harmony-unused/README.md b/examples/harmony-unused/README.md index c234e290e..3755b0558 100644 --- a/examples/harmony-unused/README.md +++ b/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 diff --git a/examples/harmony-unused/template.md b/examples/harmony-unused/template.md index b473bfc5c..556f82610 100644 --- a/examples/harmony-unused/template.md +++ b/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 diff --git a/examples/http2-aggressive-splitting/README.md b/examples/http2-aggressive-splitting/README.md index a779cd0ea..fd7a3cd49 100644 --- a/examples/http2-aggressive-splitting/README.md +++ b/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"); diff --git a/examples/http2-aggressive-splitting/template.md b/examples/http2-aggressive-splitting/template.md index d0029b92c..bca2fc0dd 100644 --- a/examples/http2-aggressive-splitting/template.md +++ b/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}}_