Context
After the May 2026 work on #655, install responsibility for the Render static site lives in two places:
render.yaml: buildCommand: pnpm install --frozen-lockfile && pnpm run build — edited but not taking effect, because Render's Blueprint isn't synced for the existing service. The live service still runs pnpm run build.
package.json: a prebuild hook gated on $RENDER that runs pnpm install --frozen-lockfile when the var is set. This is what actually keeps Render deploys green today.
So the file disagrees with reality, and install logic is duplicated.
Why the duplication happened
Render static sites don't auto-run install — buildCommand is the whole build. Pre-history-rewrite, builds rode on a persistent node_modules cache, so no install step was needed in the file. The force-push invalidated that cache and exposed the missing install. I added install in both places: render.yaml (correct location, but Blueprint changes don't auto-sync on push) and package.json prebuild (works without a dashboard action).
Options to clean up
- Sync the Blueprint in the Render dashboard so the
render.yaml buildCommand takes effect, then remove the prebuild hook from package.json. Single source of truth in render.yaml. Requires a one-time dashboard click.
- Revert the
render.yaml buildCommand change to just pnpm run build and keep the prebuild hook. Single source of truth in package.json. Portable to other static hosts that don't auto-install. No dashboard action needed.
- Leave as-is. Belt-and-suspenders — if anyone ever does sync the Blueprint, the explicit install in
render.yaml kicks in and the prebuild becomes a (cheap, idempotent) no-op since node_modules is already populated.
(3) is fine in practice but the divergence between file and reality is a footgun for anyone reading render.yaml to understand the build. (1) is cleanest if you don't mind the manual sync; (2) is cleanest if you want pure file-driven control.
Acceptance criteria
render.yaml and the actual Render build behavior agree. Whoever opens render.yaml can predict what runs on Render without also knowing about the Blueprint sync state.
Related
Context
After the May 2026 work on #655, install responsibility for the Render static site lives in two places:
render.yaml:buildCommand: pnpm install --frozen-lockfile && pnpm run build— edited but not taking effect, because Render's Blueprint isn't synced for the existing service. The live service still runspnpm run build.package.json: aprebuildhook gated on$RENDERthat runspnpm install --frozen-lockfilewhen the var is set. This is what actually keeps Render deploys green today.So the file disagrees with reality, and install logic is duplicated.
Why the duplication happened
Render static sites don't auto-run install —
buildCommandis the whole build. Pre-history-rewrite, builds rode on a persistentnode_modulescache, so no install step was needed in the file. The force-push invalidated that cache and exposed the missing install. I added install in both places:render.yaml(correct location, but Blueprint changes don't auto-sync on push) andpackage.jsonprebuild (works without a dashboard action).Options to clean up
render.yamlbuildCommandtakes effect, then remove theprebuildhook frompackage.json. Single source of truth inrender.yaml. Requires a one-time dashboard click.render.yamlbuildCommandchange to justpnpm run buildand keep theprebuildhook. Single source of truth inpackage.json. Portable to other static hosts that don't auto-install. No dashboard action needed.render.yamlkicks in and the prebuild becomes a (cheap, idempotent) no-op sincenode_modulesis already populated.(3) is fine in practice but the divergence between file and reality is a footgun for anyone reading
render.yamlto understand the build. (1) is cleanest if you don't mind the manual sync; (2) is cleanest if you want pure file-driven control.Acceptance criteria
render.yamland the actual Render build behavior agree. Whoever opensrender.yamlcan predict what runs on Render without also knowing about the Blueprint sync state.Related
--prodcan be considered)