Using vendors as entry is not recommended

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.