[Shivaansh-Agarwal]

Description

Fixes #1089.

• docker-compose up --build currently fails/crash-loops because both Dockerfiles resolve pnpm to an unpinned "latest" version, which is incompatible with the node:20-alpine base image.
• After above fix, packages/app/Dockerfile's cache cleanup step was removing the pinned pnpm version needed at container runtime.

What type of PR is this? (Check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📄 Documentation Update
• 👨‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🛠️ CI/CD

Screenshots (if applicable)

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
openlogo-prod-web	Ready	Preview	Aug 7, 2026 4:16pm
openlogo-staging-web	Ready	Preview	Aug 7, 2026 4:16pm

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[devin-ai-integration]

Code review

Diagnosis is right and the fix is minimal, but the pinning is only half-done. Note this PR is closed while stage still has corepack prepare pnpm@latest and npm install -g pnpm — so the reported breakage is still live.

Main points

1. pnpm@10 is still a floating range. A future 10.x can change Node requirements again and reproduce this exact failure. Pin an exact version and, better, declare it once in the root package.json as "packageManager": "pnpm@10.x.y"; then both Dockerfiles just need corepack enable, and pnpm/action-setup in CI picks up the same version. One source of truth instead of three.
2. Inconsistent install mechanism. packages/app/Dockerfile uses corepack while packages/ui/Dockerfile uses npm install -g pnpm@10. Use corepack in both.
3. Reproducibility gap that pinning pnpm doesn't close. pnpm-lock.yaml is gitignored (.gitignore:16) and the Dockerfiles only COPY package.json, so every image build re-resolves dependency versions — same class of problem as unpinned pnpm, plus a supply-chain risk. Commit the lockfile, COPY it, and use pnpm install --frozen-lockfile.
4. Cache cleanup. Dropping rm -rf /root/.cache fixes the runtime lookup but re-adds the corepack/pnpm cache to the final image. Cleaner alternatives: keep the cleanup and activate pnpm in the runtime layer, or set COREPACK_HOME to a path you intentionally preserve. Also packages/app/Dockerfile declares AS deps but never uses a second stage, and COPY . . ships the whole build context — a .dockerignore would help.
5. Required check is red: SonarCloud Code Analysis fails with "C Security Rating on New Code". That blocks merge regardless of the pnpm fix — worth looking at the hotspot before reopening.
6. No verification artifact. Since this is exactly the kind of thing that silently regresses, add a CI job that builds both images (or at least paste docker compose up --build output in the PR).

Was this superseded by another PR, or just abandoned? If nothing replaced it, the pnpm@latest bug is still worth fixing on stage.

Written by Devin