From 063a936db9ccb25cbe9f205398dc02778e35c1ae Mon Sep 17 00:00:00 2001 From: bakuzan Date: Wed, 10 Apr 2019 08:58:41 +0100 Subject: [PATCH 1/2] clarify production build output files. closes #6698 --- docusaurus/docs/production-build.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docusaurus/docs/production-build.md b/docusaurus/docs/production-build.md index f57e5a9b959..b0b16d69b13 100644 --- a/docusaurus/docs/production-build.md +++ b/docusaurus/docs/production-build.md @@ -5,15 +5,15 @@ title: Creating a Production Build `npm run build` creates a `build` directory with a production build of your app. Inside the `build/static` directory will be your JavaScript and CSS files. Each filename inside of `build/static` will contain a unique hash of the file contents. This hash in the file name enables [long term caching techniques](#static-file-caching). -When running a production build of freshly created Create React App application, there are 3 `.js` files (called _chunks_) that are generated and placed in the `build/static/js` directory: +When running a production build of freshly created Create React App application, there are a number of `.js` files (called _chunks_) that are generated and placed in the `build/static/js` directory: `main.[hash].chunk.js` - This is your _application_ code. `App.js`, etc. -`1.[hash].chunk.js` +`[number].[hash].chunk.js` -- This is your _vendor_ code, which includes modules you've imported from within `node_modules`. One of the potential advantages with splitting your _vendor_ and _application_ code is to enable [long term caching techniques](#static-file-caching) to improve application loading performance. Since _vendor_ code tends to change less often than the actual _application_ code, the browser will be able to cache them separately, and won't re-download them each time the app code changes. +- These files are your _vendor_ code that include modules you've imported from within `node_modules`. One of the potential advantages with splitting your _vendor_ and _application_ code is to enable [long term caching techniques](#static-file-caching) to improve application loading performance. Since _vendor_ code tends to change less often than the actual _application_ code, the browser will be able to cache them separately, and won't re-download them each time the app code changes. `runtime~main.[hash].js` From def2eefa83c966000d77cb83bb57eb7d996f8117 Mon Sep 17 00:00:00 2001 From: Ian Schmitz Date: Sat, 13 Apr 2019 22:09:50 +0100 Subject: [PATCH 2/2] Update docusaurus/docs/production-build.md Co-Authored-By: bakuzan --- docusaurus/docs/production-build.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docusaurus/docs/production-build.md b/docusaurus/docs/production-build.md index b0b16d69b13..7bafc5bf743 100644 --- a/docusaurus/docs/production-build.md +++ b/docusaurus/docs/production-build.md @@ -13,7 +13,7 @@ When running a production build of freshly created Create React App application, `[number].[hash].chunk.js` -- These files are your _vendor_ code that include modules you've imported from within `node_modules`. One of the potential advantages with splitting your _vendor_ and _application_ code is to enable [long term caching techniques](#static-file-caching) to improve application loading performance. Since _vendor_ code tends to change less often than the actual _application_ code, the browser will be able to cache them separately, and won't re-download them each time the app code changes. +- These files can either be _vendor_ code, or [code splitting chunks](code-splitting.md). _Vendor_ code includes modules that you've imported from within `node_modules`. One of the potential advantages with splitting your _vendor_ and _application_ code is to enable [long term caching techniques](#static-file-caching) to improve application loading performance. Since _vendor_ code tends to change less often than the actual _application_ code, the browser will be able to cache them separately, and won't re-download them each time the app code changes. `runtime~main.[hash].js`