When using the experimental page build optimisation (GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true), the webpack hash is not deterministic, resulting in unnecessary rebuilds.
This is due to the fact that the pages are not always emitted in the same order, causing the keys in .cache/async-requires.js to be written in a different order and producing a different hash for the module, and therefore the build.
$ GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true npm run build -- --log-pages
Gatsby starter with minimal reproduction:
https://github.com/peteris/gatsby-bug-repro-non-deterministic-builds
Since no code or content has changed, the build hash should not change and no pages should be emitted.
Pages are still periodically emitted. This is due to the fact that the pages are not always emitted in the same order, causing the keys in .cache/async-requires.js to be written in a different order and producing a different hash for the module, and the build.
Potential solution
I believe all we need to do is sort the keys in this function.
// before
.uniqBy(c => c.componentChunkName)
// after
.uniqBy(c => c.componentChunkName)
.orderBy(c => c.componentChunkName)
I'm happy to open a PR if a maintainer can +1 this idea.
System:
OS: macOS 10.15.4
CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 12.6.0 - ~/.nave/installed/12.6.0/bin/node
npm: 6.9.0 - ~/.nave/installed/12.6.0/bin/npm
Languages:
Python: 2.7.16 - /usr/bin/python
Browsers:
Chrome: 80.0.3987.163
Safari: 13.1
npmPackages:
gatsby: ^2.20.12 => 2.20.12
I started writing reply suggesting exactly same solution that you did, before realizing you provided it. So definitely "+1" on your solution and pull request like is more than welcome
Thanks @pieh , I've opened https://github.com/gatsbyjs/gatsby/pull/22965
Most helpful comment
I started writing reply suggesting exactly same solution that you did, before realizing you provided it. So definitely "+1" on your solution and pull request like is more than welcome