The config is quite large, but here are some of the important values in the final output.
There's a lot going on here. And this is just a sample of the output that doesn't include the loaders, rules, etc. We won't go over everything here, but most of it is geared towards proper code splitting of your application.
This contains the small webpack-runtime as a separate bundle (configured in optimization section). In practice, the app and webpack-runtime are always needed together.
This is a separate bundle for each page. The mechanics for how these are split off from the main production app are covered in Code Splitting.
This is the entrypoint to webpack that outputs app-[contenthash].js bundle. It is responsible for navigation and page loading once the initial HTML has been loaded.
Then, the app, webpack-runtime, component, and data json bundles are loaded via <link> and <script> (see HTML tag generation). Now, our production-app code starts running.
The first thing our app does is run the onClientEntry browser API. This allows plugins to perform any operations before we hit the rest of the page loading logic. For example gatsby-plugin-glamor will call rehydrate.
It's worth noting that the browser API runner is completely different to api-runner-node which is explained in How APIs/Plugins Are Run. api-runner-node runs in Node.js and has to deal with complex server based execution paths. Whereas running APIs on the browser is simply a matter of iterating through the site's registered browser plugins and running them one after the other (see api-runner-browser.js).
One thing to note is that it gets the list of plugins from ./cache/api-runner-browser-plugins.js, which is generated early in bootstrap.
hydrate() is a ReactDOM function which is the same as render(), except that instead of generating a new DOM tree and inserting it into the document, it expects that a React DOM already exists with exactly the same structure as the React Model. It therefore descends this tree and attaches the appropriate event listeners to it so that it becomes a live React DOM. Since our HTML was rendered with exactly the same code as we're running in our browser, these will (and have to) match perfectly. The hydration occurs on the <div id="___gatsby">...</div> element defined in default-html.js.
The hydration requires a new React component to "replace" the existing DOM with. Gatsby uses reach router for this. Within it, we provide a RouteHandler component that uses PageRenderer to create the navigated to page.
PageRenderer's constructor loads the page resources for the path. On first load though, these will have already been requested from the server by <link rel="preload" ... /> in the page's original HTML (see Link Preloads in HTML Generation Docs). The loaded page resources includes the imported component, with which we create the actual page component using React.createElement(). This element is returned to our RouteHandler which hands it off to Reach Router for rendering.
Before hydration occurs, we kick off the loading of resources in the background. As mentioned above, the current page's resources will have already been requested by link tags in the HTML. So, technically, there's nothing more required for this page load. But we can start loading resources required to navigate to other pages.
This occurs in loader.js. The main function here is getResourcesForPathname(). Given a path, it will find its page, and import its component module json query results. But to do this, it needs access to that information. This is provided by async-requires.js which contains the list of all pages in the site, and all their dataPaths. fetchPageResourcesMap() takes care of requesting that file, which occurs the first time getResourcesForPathname() is called.
This is a reference to the loader.js object that can be used for getting page resources and enqueueing prefetch commands. It is used by gatsby-link to prefetch pages. And by gatsby-plugin-guess-js to implement its own prefetching algorithm.
Contents of chunk-map.json. See Code Splitting for more.
These are set in init navigation. Used by gatsby-link to override navigation behavior so that it loads pages before using reach to navigate.