fix: repair docker build by pinning pnpm and approving dependency build scripts

[nyeinphyoaung]

The problem

docker compose build failed at pnpm install --frozen-lockfile with ERR_PNPM_IGNORED_BUILDS.

Nothing in the repo caused it. The Dockerfile ran corepack prepare pnpm@latest --activate, so the container silently moved to pnpm 11.22.0 when it was released, while local development was still on pnpm 10.20.0. pnpm 11 turns "ignored dependency build scripts" from a warning into a hard error, so the install exited 1 and the image could not be built at all.

Fixes

1. Pin the package manager so the container, CI and local machines all resolve the same pnpm:

"packageManager": "pnpm@11.22.0"

The Dockerfile now uses plain corepack enable, which honours that field instead of fetching whatever is newest. Build log confirms Done in 46.8s using pnpm v11.22.0.

2. Approve the dependency build scripts that genuinely need to run, in pnpm-workspace.yaml:

allowBuilds:
  esbuild: true
  sharp: true
  unrs-resolver: true

• sharp compiles the native libvips binary used by next/image (5 files in the app use it)
• esbuild fetches its platform binary, needed by tsx / drizzle-kit for the db:* scripts
• unrs-resolver is a native binding for the ESLint import resolver

This is the documented pnpm 11 format, not a workaround. Per pnpm's build settings reference, allowBuilds was added in v10.26.0 and takes a package-to-boolean map in pnpm-workspace.yaml. The docs state that onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies and ignoreDepScripts were removed in v11 and replaced by allowBuilds, with onlyBuiltDependencies: [electron] converting to allowBuilds: {electron: true}.

That also explains the two dead ends hit on the way here: onlyBuiltDependencies in package.json is ignored outright by pnpm 11, and the same key in pnpm-workspace.yaml is still readable via pnpm config get but no longer gates the install. pnpm approve-builds --all generates the correct form.

3. Copy the config into the image. The deps stage only copied two files, so the container never saw the new config:

-COPY package.json pnpm-lock.yaml ./
+COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./

4. ENV HUSKY=0 in the deps stage. .dockerignore excludes .git, so prepare: husky failed noisily on every build. The variable already existed but only in the builder stage, after install had run.

5. Removed the stale GOOGLE_GENERATIVE_AI_API_KEY build arg from both the Dockerfile and compose file, left over from the removed AI integration.

Verification

Built clean with --no-cache, then run and exercised:

• image builds green, 229MB
• container boots, Ready, no errors in logs
• / and /sign-in return 200; /dashboard and /ai-chat return 307 to sign-in (auth gating correct)
• POST /api/auth/sign-in/email returns the seeded user and a session token, so the container reaches Postgres
• sharp is present in the runtime image, so image optimisation works
• no secrets in the shipped image - docker inspect env and layer history are clean, since the multi-stage build discards the builder stage

pnpm-lock.yaml is unchanged.

Consequence worth knowing

Corepack will now switch anyone in this repo to pnpm 11.22.0 automatically. That is the intent - it is what stops the version drifting again - but upgrading pnpm in future means bumping that line rather than just installing a newer version globally.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
shadcn-admindashboard	Ready	Preview	Aug 22, 2026 7:03pm

[claude]

Claude finished @nyeinphyoaung's task in 2m 30s —— View job

---

Code Review: fix: repair docker build by pinning pnpm and approving dependency build scripts

Summary

This is a small, well-scoped infra fix that pins the package manager and re-approves the native build scripts pnpm 11 now hard-blocks by default. The author's manual verification (clean --no-cache build, boot, auth flow, sharp presence) is thorough. The main gaps are process-level: nothing in CI actually builds the Docker image, so a regression like this one won't be caught automatically next time, and the correctness of the new allowBuilds key in pnpm-workspace.yaml rests entirely on the author's local build log rather than something checkable in this diff.

---

Medium Issues

1. No CI coverage for the Docker build (Dockerfile, docker-compose.yml)

This PR exists because docker compose build broke silently on a pnpm@latest drift, and nobody noticed until someone tried to build. The repo's current checks (Branch Naming Convention, Claude Code Review) don't include a docker build step, so this exact class of failure — an unpinned tool silently moving forward and breaking the image — can recur without any signal until a person happens to build locally again.

# no workflow currently runs:
docker build -t shadcn-admin:ci .

Consider adding a lightweight docker build job to CI (even without pushing the image) so the fix in this PR is continuously enforced rather than a one-time manual verification.

2. allowBuilds in pnpm-workspace.yaml is unusual and worth double-checking against pnpm's docs (pnpm-workspace.yaml:1)

allowBuilds:
  esbuild: true
  sharp: true
  unrs-resolver: true

The PR body is explicit that this key was reached by trial and error (onlyBuiltDependencies didn't gate the install, allowBuilds did, generated via pnpm approve-builds --all). That's plausible for a brand-new pnpm 11 behavior, and the author's build log backs it up, but this repo has no automated way to re-verify it if pnpm patches the format again — it will only be caught the same way this bug was: someone's local build breaking. Worth linking the pnpm 11 changelog/docs entry that documents allowBuilds in the PR description for future maintainers, and pairing with issue #1 (CI build check) so a silent regression here is caught immediately instead of drifting again.

---

Minor Issues

3. COREPACK_ENABLE_DOWNLOAD_PROMPT=0 set after corepack enable in both stages (Dockerfile:7-8, Dockerfile:17-18)

Functionally harmless since the env var is only read on the next pnpm invocation, not by corepack enable itself, but placing the ENV line before the RUN corepack enable line would read more intuitively as "configure corepack, then enable it."

4. Builder stage's ENV HUSKY=0 is now redundant with the deps-stage fix (Dockerfile:9, Dockerfile:24)

HUSKY=0 in the builder stage (pre-existing, line 24) only mattered when install happened after COPY . . there. Now that the real install (and thus the prepare hook) runs entirely in the deps stage where HUSKY=0 is newly set (line 9), the builder-stage copy is inert. Not wrong, just leftover — fine to leave as a defensive no-op, but a one-line comment would save the next reader from wondering why it's duplicated.

---

Strengths

• Root-caused correctly: identified that corepack prepare pnpm@latest --activate was the source of drift between local (pnpm 10) and container (pnpm 11), rather than treating the symptom (ERR_PNPM_IGNORED_BUILDS) in isolation.
• packageManager: "pnpm@11.22.0" in package.json:4 combined with plain corepack enable is the currently-recommended Docker pattern (deterministic version resolution instead of "latest").
• Correctly identified and fixed the second, unrelated failure mode (husky prepare script failing because .dockerignore excludes .git) in the same pass rather than leaving a partially-fixed image.
• Cleaned up the stale GOOGLE_GENERATIVE_AI_API_KEY build arg from both Dockerfile and docker-compose.yml consistently — confirmed no other references remain in the repo.
• pnpm-lock.yaml is unchanged, so this stays a build-tooling fix with no dependency version drift.

---

Verdict: No critical issues. Remaining items can be iterated on later — recommend adding a CI docker build step as a near-term follow-up so this class of regression is caught automatically next time pnpm ships a breaking release.

[claude]

Claude finished @nyeinphyoaung's task in 2m 13s —— View job

---

Code Review: fix: repair docker build by pinning pnpm and approving dependency build scripts

Summary

This is a small, well-scoped infra fix that correctly root-causes the ERR_PNPM_IGNORED_BUILDS failure (unpinned corepack prepare pnpm@latest silently drifting to pnpm 11) and pins the toolchain via packageManager. The Dockerfile changes are internally consistent (env vars are set before corepack enable in both stages, and the pinned package.json lands before each pnpm invocation reads it). The main gaps are process-level: there's no CI step that actually builds the Docker image, and the correctness of the new allowBuilds key in pnpm-workspace.yaml can't be verified from this diff alone.

---

Medium Issues

1. No CI coverage for the Docker build (Dockerfile, docker-compose.yml)

This PR exists because docker compose build broke silently on a pnpm@latest drift, and nobody noticed until someone tried to build locally. None of the repo's current checks run docker build, so this exact failure class - an unpinned tool moving forward and breaking the image - can recur silently again.

# no workflow currently runs:
docker build -t shadcn-admin:ci .

Consider adding a lightweight docker build job to CI (even without pushing the image) so this fix stays enforced instead of relying on manual verification each time.

2. allowBuilds in pnpm-workspace.yaml is not a documented/stable pnpm-workspace key as of my last knowledge (pnpm-workspace.yaml:1)

allowBuilds:
  esbuild: true
  sharp: true
  unrs-resolver: true

The historically documented mechanism for this is onlyBuiltDependencies (an array of package names) in pnpm-workspace.yaml or the pnpm.onlyBuiltDependencies field in package.json - the PR description itself notes both of those were tried and silently ignored by pnpm 11. allowBuilds may well be a new pnpm 11 key (generated by pnpm approve-builds --all, per the PR description, and the author's build log confirms esbuild/sharp/unrs-resolver install cleanly), but this repo has no automated way to re-verify the key/schema if pnpm changes it again in a patch release - it will only surface the same way this bug did, via a broken local build. Worth linking the pnpm 11 changelog/docs entry for allowBuilds in the PR description for future maintainers, and pairing with issue #1 so a regression here is caught by CI instead of drifting silently.

Confirmed independently: sharp, esbuild, and unrs-resolver are all transitive dependencies (pulled in by Next.js image optimization, tsx/drizzle-kit, and the ESLint import resolver respectively) - none appear in package.json dependencies/devDependencies - so they wouldn't have been coverable by a pnpm.onlyBuiltDependencies list a developer might hand-write without first running pnpm approve-builds.

---

Minor Issues

3. Builder stage's ENV HUSKY=0 is now redundant (Dockerfile:24)

HUSKY=0 in the builder stage only mattered when install (and thus the prepare hook) happened there. Now that install runs entirely in the deps stage, where HUSKY=0 is already set (Dockerfile:8), and node_modules is copied rather than reinstalled in builder, this line is inert. Not wrong, just dead weight - safe to leave, but a one-line comment would save the next reader from wondering why it's duplicated.

---

Strengths

• Root-caused correctly: pinpointed corepack prepare pnpm@latest --activate as the source of local/container version drift, rather than patching around the symptom (ERR_PNPM_IGNORED_BUILDS).
• packageManager: "pnpm@11.22.0" in package.json:4 combined with plain corepack enable is the correct pattern for deterministic version resolution in Docker.
• Env-var ordering was fixed in the second commit (bc66320) so COREPACK_ENABLE_DOWNLOAD_PROMPT/HUSKY are now set before corepack enable runs in both stages - reads correctly top to bottom.
• Correctly identified and fixed the unrelated husky prepare-script failure (.dockerignore excludes .git) in the same pass rather than shipping a partially-fixed image.
• Cleaned up the stale GOOGLE_GENERATIVE_AI_API_KEY build arg consistently from both Dockerfile and docker-compose.yml - confirmed no remaining references anywhere in the repo.
• pnpm-lock.yaml is unchanged, so this stays a build-tooling fix with no dependency version drift.

---

Verdict: No critical issues. Recommend adding a CI docker build step (#1) as a near-term follow-up, and linking the pnpm 11 allowBuilds documentation (#2) so the next maintainer isn't left reverse-engineering it from a build log.