fix(setup): use --frozen-lockfile in setup hook to stop lockfile churn

[claude]

Requested by Damien Garros · Slack thread

Why

Every new Infrahub workspace came up dirty: frontend/pnpm-lock.yaml had uncommitted modifications, and the SessionStart hook reported SessionStart:startup hook error.

The pnpm version is not the problem. The workspace-root frontend/package.json already pins "packageManager": "pnpm@10.33.2", and the ambient pnpm self-switches to that version correctly — even when invoked from the frontend/app subdirectory. So there is no version drift to fix.

The real cause is the setup hook running a bare pnpm install. That command normalizes and rewrites frontend/pnpm-lock.yaml on a fresh workspace, producing the uncommitted lockfile churn. And because dev/setup-environment.sh runs under set -e, any non-zero exit from that install step aborts the script — which is exactly what surfaced as the SessionStart:startup hook error.

Before / After

• Before: Every new workspace ended up with uncommitted changes in frontend/pnpm-lock.yaml, and the SessionStart hook reported SessionStart:startup hook error when the install step exited non-zero under set -e.
• After: Fresh workspaces come up clean — no lockfile churn — and the setup hook completes successfully.

What changed

• dev/setup-environment.sh — changed the frontend install step from a bare pnpm install to pnpm install --frozen-lockfile || echo "Warning: pnpm install failed (continuing)".
  • --frozen-lockfile stops the setup hook from mutating frontend/pnpm-lock.yaml: instead of silently rewriting the lockfile, pnpm installs strictly from the committed one, and a genuinely out-of-sync lockfile now fails loudly instead of churning silently.
  • The || echo "Warning: ..." non-fatal guard matches the pattern the existing gh install step already uses, so a transient install hiccup can't abort the whole set -e setup script and turn into a hook error.

How

The single-line change in dev/setup-environment.sh makes the install deterministic (frozen against the committed lockfile) and non-fatal (guarded), so setup can neither mutate the lockfile nor abort the hook.

How to test

# From a clean checkout
CLAUDE_ENV_FILE=/tmp/env.sh bash dev/setup-environment.sh
git status   # tree should be clean — no frontend/pnpm-lock.yaml diff

Verified: running the setup hook now exits 0 and leaves a clean working tree (no lockfile diff). pnpm self-switches to the root-pinned pnpm@10.33.2 and the frozen install completes cleanly.

Impact & rollout

• Backward compatibility: none — the change only affects the setup hook's install invocation.
• Config/env changes: none.
• Deployment notes: safe to deploy.

Follow-ups (out of scope for this PR)

• dev/setup-environment.sh guards its env-export block on $ENV_FILE but detection uses $CLAUDE_ENV_FILE, so INFRAHUB_PROJECT_DIR and the .venv PATH are silently never written under the claude-code-web branch. Small, unrelated.
• frontend/app/package.json has engines.node: ">=24" while some environments still run node 22, producing Unsupported engine warnings on every install.