fix: drop the dead HUGO_VERSION pin from the Netlify config - #2110
Merged
Conversation
Netlify installed Hugo 0.153.1 on every build and then never used it. The build invokes `hugo` from an npm script, which resolves to node_modules/.bin/hugo provided by the hugo-extended dependency, so the binary Netlify downloads for HUGO_VERSION is discarded. The pin therefore only created drift between the version anyone reading the Netlify config would trust and the binary that actually ran, plus a pointless download on every build. package.json remains the single pin. Remove the key from data/netlify.toml, the real source: netlify.toml is generated from it and carries a do-not-modify header. The generated output is regenerated to match. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for gethinode-demo ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
markdumay
enabled auto-merge
August 2, 2026 11:01
Collaborator
Author
|
🎉 This PR is included in version 3.16.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Problem
Netlify installed Hugo
0.153.1on every build and then never used it.The build invokes
hugofrom an npm script, which resolves tonode_modules/.bin/hugofrom thehugo-extendeddependency — shadowing the binary Netlify installed. So the pin was adrift from the version that actually ran, and cost a pointless download each build. Anyone reading the Netlify config to find out which Hugo builds this project got the wrong answer.This was found via a gethinode.com deploy log showing both halves at once:
Hugo version set to 0.153.1followed byhugo v0.164.0+extended.Changes
Remove
HUGO_VERSION, leavingpackage.jsonas the single pin. A comment records why the key is absent so it does not get restored later.Where
netlify.tomlis generated fromdata/netlify.toml(do-not-modify header), the source file is edited and the generated output updated to match — a deletion-only change.Verification
The mechanism was verified end-to-end in gethinode.com: regenerating with no change reproduced the committed
netlify.tomlbyte-for-byte, and regenerating after the removal produced exactly one deleted line, with no module-suppliedHUGO_VERSIONmerging back in to replace it.Each repo in this sweep was checked to confirm
hugo-extendedis a dependency and the Netlify build command routes through npm/pnpm scripts before the key was touched. Repos without an npm Hugo (gethinode/customization-demo,gethinode/version-demo) were deliberately excluded — their pin is load-bearing.🤖 Generated with Claude Code