fix: stop baking the build date into the client bundle - #9
Merged
Merged
Conversation
LandingPage inlined `new Date().toDateString()` via preval, so the bundle's content hash changed on any build on a new day even when the client source was byte-identical. Every release invalidated every viewer's cached bundle, the bundle name could not answer "did the client change?", and release artifacts were not reproducible. Show the package version instead -- the landing page already had a REACT_APP_VERSION block, but nothing ever set it, so the date was the only thing rendered. The build script now wires it from $npm_package_version. Also make release.yml use `yarn install --frozen-lockfile`, matching FORK.md's local recipe; a release job should not be free to resolve around the lockfile. Verified: built under TZ=Pacific/Kiritimati (Thu Aug 27) and TZ=Etc/GMT+12 (Wed Aug 26) -- both give main.e9cc62a6.js, and no date string survives in the bundle. Previously post1 (Aug 25) gave main.ca3f787c.js and post2 (Aug 26) main.9857844c.js from identical sources. Closes #2 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BQnnW5jCKXnefXA89eBDoL
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2.
src/LandingPage.jsinlinednew Date().toDateString()throughpreval, so the bundle's contenthash changed on any build on a new day even when the client source was byte-identical.
Still live as of today. The release I cut an hour ago reproduced it: client source is identical
between
quadbio-1.1.61.post2andquadbio-1.1.61+quadbio.3(git diffoversrc/ public/ package.json yarn.lockis empty), yet the shipped bundle wentmain.9857844c.js→main.3ed24ed0.js.Fix — show the package version instead of the date. The landing page already had a
REACT_APP_VERSIONblock, but nothing ever set it, so the date was the only thing renderingthere. The build script now wires it from
$npm_package_version.Verified by building the same source under two timezones that are on different calendar days:
TZ=Pacific/Kiritimatimain.e9cc62a6.jsTZ=Etc/GMT+12main.e9cc62a6.jsIdentical. No date string survives in the bundle (
grepforAug 27 2026,Aug 26 2026,Thu Aug,Wed Aug,Tue Aug→ 0 hits), andVersion:+1.1.61are present instead. The bundle is252 bytes smaller.
For contrast, before this change: post1 (Aug 25) →
main.ca3f787c.js, post2 (Aug 26) →main.9857844c.js, from identical sources.Also, per the issue's aside:
release.ymlnow usesyarn install --frozen-lockfile, matchingFORK.md's local Euler recipe. A release job should not be free to resolve around the lockfile.
preval.macrois left indevDependenciesdeliberately — removing it would mean regeneratingyarn.lock, and a large lockfile churn is not worth it inside a fix whose whole point is buildreproducibility. Worth a follow-up.