diff --git a/src/content/concepts/entry-points.md b/src/content/concepts/entry-points.md index 0a6bbf0695ff..8aacddf83fa0 100644 --- a/src/content/concepts/entry-points.md +++ b/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}` 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.