Merge branch 'master' into SplitChunksPluginTypo

Author: sakhisheikh

src/content/concepts/entry-points.md

@@ -5,6 +5,7 @@ contributors:
   - TheLarkInn
   - chrisVillanueva
   - byzyk
+  - sokra
 ---
 
 As mentioned in [Getting Started](/guides/getting-started/#using-a-configuration), there are multiple ways to define the `entry` property in your webpack configuration. We will show you the ways you **can** configure the `entry` property, in addition to explaining why it may be useful to you.
@@ -47,7 +48,7 @@ Usage: `entry: {[entryChunkName: string]: string|Array<string>}`
 module.exports = {
   entry: {
     app: './src/app.js',
-    vendors: './src/vendors.js'
+    adminApp: './src/adminApp.js'
   }
 };
 ```
@@ -61,26 +62,9 @@ T> **"Scalable webpack configurations"** are ones that can be reused and combine
 
 Below is a list of entry configurations and their real-world use cases:
 
-
 ### Separate App and Vendor Entries
 
-**webpack.config.js**
-
-```javascript
-module.exports = {
-  entry: {
-    app: './src/app.js',
-    vendors: './src/vendors.js'
-  }
-};
-```
-
-**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).
-
-?> Consider removing this scenario in favor of the DllPlugin, which provides a better vendor-splitting.
-
+T> In webpack version < 4 it was common to add vendors as separate entrypoint to compile it as separate file (in combination with the `CommonsChunkPlugin`). This is discouraged in webpack 4. Instead the `optimization.splitChunks` option takes care of separating vendors and app modules and creating a separate file. **Do not** create a entry for vendors or other stuff which is not the starting point of execution.
 
 ### Multi Page Application
 
@@ -100,6 +84,6 @@ module.exports = {
 
 **Why?** In a multi-page application, the server is going to fetch a new HTML document for you. The page reloads this new document and assets are redownloaded. However, this gives us the unique opportunity to do multiple things:
 
-- Use `CommonsChunkPlugin` to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the amount of entry points increase.
+- Use `optimization.splitChunks` to create bundles of shared application code between each page. Multi-page applications that reuse a lot of code/modules between entry points can greatly benefit from these techniques, as the amount of entry points increase.
 
 T> As a rule of thumb: for each HTML document use exactly one entry point.

src/content/contribute/plugin-patterns.md

@@ -1,6 +1,8 @@
 ---
 title: Plugin Patterns
 sort: 5
+contributors:
+  - nveenjain
 ---
 
 Plugins grant unlimited opportunity to perform customizations within the webpack build system. This allows you to create custom asset types, perform unique build modifications, or even enhance the webpack runtime while using middleware. The following are some features of webpack that become useful while writing plugins.
@@ -10,63 +12,66 @@ Plugins grant unlimited opportunity to perform customizations within the webpack
 After a compilation is sealed, all structures within the compilation may be traversed.
 
 ```javascript
-function MyPlugin() {}
-
-MyPlugin.prototype.apply = function(compiler) {
-  compiler.plugin('emit', function(compilation, callback) {
-
-    // Explore each chunk (build output):
-    compilation.chunks.forEach(function(chunk) {
-      // Explore each module within the chunk (built inputs):
-      chunk.modules.forEach(function(module) {
-        // Explore each source file path that was included into the module:
-        module.fileDependencies.forEach(function(filepath) {
-          // we've learned a lot about the source structure now...
+class MyPlugin {
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      // Explore each chunk (build output):
+      compilation.chunks.forEach(chunk => {
+        // Explore each module within the chunk (built inputs):
+        chunk.modules.forEach(module => {
+          // Explore each source file path that was included into the module:
+          module.fileDependencies.forEach(filepath => {
+            // we've learned a lot about the source structure now...
+          });
         });
-      });
 
-      // Explore each asset filename generated by the chunk:
-      chunk.files.forEach(function(filename) {
-        // Get the asset source for each file generated by the chunk:
-        var source = compilation.assets[filename].source();
+        // Explore each asset filename generated by the chunk:
+        chunk.files.forEach(filename => {
+          // Get the asset source for each file generated by the chunk:
+          var source = compilation.assets[filename].source();
+        });
       });
-    });
-
-    callback();
-  });
-};
 
+      callback();
+    });
+  }
+}
 module.exports = MyPlugin;
 ```
 
-- `compilation.modules`: An array of modules (built inputs) in the compilation. Each module manages the build of a raw file from your source library.
-- `module.fileDependencies`: An array of source file paths included into a module. This includes the source JavaScript file itself (ex: `index.js`), and all dependency asset files (stylesheets, images, etc) that it has required. Reviewing dependencies is useful for seeing what source files belong to a module.
-- `compilation.chunks`: An array of chunks (build outputs) in the compilation. Each chunk manages the composition of a final rendered assets.
-- `chunk.modules`: An array of modules that are included into a chunk. By extension, you may look through each module's dependencies to see what raw source files fed into a chunk.
-- `chunk.files`: An array of output filenames generated by the chunk. You may access these asset sources from the `compilation.assets` table.
+* `compilation.modules`: An array of modules (built inputs) in the compilation. Each module manages the build of a raw file from your source library.
+* `module.fileDependencies`: An array of source file paths included into a module. This includes the source JavaScript file itself (ex: `index.js`), and all dependency asset files (stylesheets, images, etc) that it has required. Reviewing dependencies is useful for seeing what source files belong to a module.
+* `compilation.chunks`: An array of chunks (build outputs) in the compilation. Each chunk manages the composition of a final rendered assets.
+* `chunk.modules`: An array of modules that are included into a chunk. By extension, you may look through each module's dependencies to see what raw source files fed into a chunk.
+* `chunk.files`: An array of output filenames generated by the chunk. You may access these asset sources from the `compilation.assets` table.
 
 ### Monitoring the watch graph
 
 While running webpack middleware, each compilation includes a `fileDependencies` array (what files are being watched) and a `fileTimestamps` hash that maps watched file paths to a timestamp. These are extremely useful for detecting what files have changed within the compilation:
 
 ```javascript
-function MyPlugin() {
-  this.startTime = Date.now();
-  this.prevTimestamps = {};
+class MyPlugin {
+  constructor() {
+    this.startTime = Date.now();
+    this.prevTimestamps = {};
+  }
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      var changedFiles = Object.keys(compilation.fileTimestamps).filter(
+        watchfile => {
+          return (
+            (this.prevTimestamps[watchfile] || this.startTime) <
+            (compilation.fileTimestamps[watchfile] || Infinity)
+          );
+        }
+      );
+
+      this.prevTimestamps = compilation.fileTimestamps;
+      callback();
+    });
+  }
 }
 
-MyPlugin.prototype.apply = function(compiler) {
-  compiler.plugin('emit', function(compilation, callback) {
-
-    var changedFiles = Object.keys(compilation.fileTimestamps).filter(function(watchfile) {
-      return (this.prevTimestamps[watchfile] || this.startTime) < (compilation.fileTimestamps[watchfile] || Infinity);
-    }.bind(this));
-
-    this.prevTimestamps = compilation.fileTimestamps;
-    callback();
-  }.bind(this));
-};
-
 module.exports = MyPlugin;
 ```
 
@@ -77,22 +82,21 @@ You may also feed new file paths into the watch graph to receive compilation tri
 Similar to the watch graph, it's fairly simple to monitor changed chunks (or modules, for that matter) within a compilation by tracking their hashes.
 
 ```javascript
-function MyPlugin() {
-  this.chunkVersions = {};
+class MyPlugin {
+  constructor() {
+    this.chunkVersions = {};
+  }
+  apply(compiler) {
+    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
+      var changedChunks = compilation.chunks.filter(chunk => {
+        var oldVersion = this.chunkVersions[chunk.name];
+        this.chunkVersions[chunk.name] = chunk.hash;
+        return chunk.hash !== oldVersion;
+      });
+      callback();
+    });
+  }
 }
 
-MyPlugin.prototype.apply = function(compiler) {
-  compiler.plugin('emit', function(compilation, callback) {
-
-    var changedChunks = compilation.chunks.filter(function(chunk) {
-      var oldVersion = this.chunkVersions[chunk.name];
-      this.chunkVersions[chunk.name] = chunk.hash;
-      return chunk.hash !== oldVersion;
-    }.bind(this));
-
-    callback();
-  }.bind(this));
-};
-
 module.exports = MyPlugin;
 ```