Skip to content

Resolve render.yaml vs live Blueprint drift (install step + prebuild hook duplication) #657

@narthur

Description

@narthur

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

  1. 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.
  2. 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.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    DEVINFInfrastructure, opposite of UVI

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions