From 063a936db9ccb25cbe9f205398dc02778e35c1ae Mon Sep 17 00:00:00 2001
From: bakuzan <imannoyed4days@hotmail.co.uk>
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 f57e5a9b9..b0b16d69b 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`
 
-- 
GitLab


From def2eefa83c966000d77cb83bb57eb7d996f8117 Mon Sep 17 00:00:00 2001
From: Ian Schmitz <ianschmitz@gmail.com>
Date: Sat, 13 Apr 2019 22:09:50 +0100
Subject: [PATCH 2/2] Update docusaurus/docs/production-build.md

Co-Authored-By: bakuzan <imannoyed4days@hotmail.co.uk>
---
 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 b0b16d69b..7bafc5bf7 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`
 
-- 
GitLab