Dev

[UGing265]

Summary by CodeRabbit

• Bug Fixes

  • Resolved legacy environment variable syntax warnings in the Docker build process.

• Chores

  • Updated package manager installation approach in the build infrastructure for improved maintainability.

[qodo-code-review]

Review Summary by Qodo

Fix frontend Dockerfile ENV syntax and pnpm installation

🐞 Bug fix 📝 Documentation

Walkthroughs

Description

• Updated frontend Dockerfile ENV syntax from legacy space-separated to modern key=value format
• Changed pnpm installation method from corepack to global npm install
• Recorded Dockerfile fixes in CHANGELOG for v1.0.1 release

Diagram

flowchart LR
  A["Legacy ENV Syntax<br/>ENV KEY VALUE"] -->|"Update to modern format"| B["Modern ENV Syntax<br/>ENV KEY=VALUE"]
  C["Corepack pnpm<br/>Installation"] -->|"Replace with"| D["Global npm install<br/>pnpm@latest"]
  B --> E["Updated Dockerfile"]
  D --> E
  E --> F["CHANGELOG Updated<br/>v1.0.1"]

Loading

File Changes

1. frontend/Dockerfile 🐞 Bug fix +7/-8

Modernize ENV syntax and pnpm installation

• Updated all ENV declarations to use modern key=value format instead of legacy space-separated
 syntax
• Changed pnpm installation from corepack enable pnpm to npm install -g pnpm@latest in base
 stage
• Affected environment variables: NEXT_TELEMETRY_DISABLED, NODE_ENV, PORT, and HOSTNAME

frontend/Dockerfile

---

2. CHANGELOG.md 📝 Documentation +4/-0

Document v1.0.1 Dockerfile fixes

• Added new v1.0.1 release section dated 2026-03-25
• Documented fix for legacy ENV syntax warnings in frontend Dockerfile
• Updated to modern key=value format in changelog entry

CHANGELOG.md

---

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: dab5227e-2445-4cf5-8431-1cc5d52b9ef9

📥 Commits

Reviewing files that changed from the base of the PR and between 1ec8c5a and 79194bb.

📒 Files selected for processing (2)

• CHANGELOG.md
• frontend/Dockerfile

---

📝 Walkthrough

Walkthrough

This pull request updates the frontend Dockerfile to modernize environment variable syntax from legacy space/quote format to KEY=VALUE format, and switches pnpm installation from corepack to npm in the base stage. A corresponding changelog entry documents the fix.

Changes

Cohort / File(s)	Summary
Documentation CHANGELOG.md	Added version 1.0.1 release entry documenting the fix for legacy ENV syntax warnings in the frontend Dockerfile.
Docker Configuration frontend/Dockerfile	Converted environment variable declarations (NEXT_TELEMETRY_DISABLED, NODE_ENV, PORT, HOSTNAME) from legacy space/quote syntax to modern KEY=VALUE format across build and runtime stages. Changed pnpm installation method from corepack enable pnpm in deps stage to npm install pnpm@latest globally in base stage.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A hop and a skip through Docker we go,
Old syntax warnings bid farewell, we know,
KEY=VALUE clarity, shiny and new,
pnpm installed right—our build runs true!
Modernized images, no warnings in sight, 🚀

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 📐 Spec deviations (0)

1. Unpinned pnpm version 🐞 Bug ⛯ Reliability

Description

The frontend Docker build installs pnpm via pnpm@latest, making builds non-reproducible and
vulnerable to future pnpm major changes that can break pnpm i --frozen-lockfile without any repo
changes. This can cause unexpected CI/CD and Docker build failures over time.

Code

frontend/Dockerfile[R3-4]

+RUN npm install -g pnpm@latest
+

Evidence

The Dockerfile now installs an unpinned pnpm version (pnpm@latest) and then uses it for frozen
lockfile installs. The repo’s lockfile uses lockfile format v9, and package.json does not pin the
package manager version (so Corepack can’t enforce a consistent pnpm version), meaning a future
latest could become incompatible and make --frozen-lockfile fail.

frontend/Dockerfile[1-18]
frontend/Dockerfile[11-14]
frontend/pnpm-lock.yaml[1-6]
frontend/package.json[1-41]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`frontend/Dockerfile` installs `pnpm@latest`, which makes builds non-reproducible and can break `pnpm i --frozen-lockfile` when pnpm releases a new major/lockfile format.

### Issue Context
The repo has `frontend/pnpm-lock.yaml` with `lockfileVersion: '9.0'` and `frontend/package.json` does not declare a `packageManager` field.

### Fix Focus Areas
- frontend/Dockerfile[1-18]
- frontend/package.json[1-41]

### Suggested fix
Either:
1) Pin pnpm in Dockerfile (e.g., `RUN npm i -g pnpm@<exact_version>`), or
2) Prefer Corepack + pin in `package.json` (add `"packageManager": "pnpm@<exact_version>"`) and use Corepack consistently in build stages.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Runner ships unused pnpm 🐞 Bug ⛨ Security

Description

Because pnpm is installed in the shared base stage, the production runner stage inherits pnpm
even though it only runs node server.js. This increases final image size and expands the
supply-chain/attack surface in production unnecessarily.

Code

frontend/Dockerfile[R1-4]

FROM node:20-alpine AS base

+RUN npm install -g pnpm@latest
+

Evidence

The base stage installs pnpm globally, and runner is built FROM base, so pnpm is present in
the runtime image. The runtime container only executes node server.js, so pnpm is unused there.

frontend/Dockerfile[1-4]
frontend/Dockerfile[30-54]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The production `runner` image inherits a globally installed pnpm from `base`, even though runtime only needs Node to run `server.js`.

### Issue Context
`FROM base AS runner` pulls in everything from `base`, including global npm packages.

### Fix Focus Areas
- frontend/Dockerfile[1-4]
- frontend/Dockerfile[30-54]

### Suggested fix
Move pnpm installation out of `base` and into only the build stages that need it (e.g., `deps` and/or `builder`). Keep `runner` based on a minimal Node image/stage without pnpm installed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Unpinned pnpm version 🐞 Bug ⛯ Reliability

The frontend Docker build installs pnpm via pnpm@latest, making builds non-reproducible and
vulnerable to future pnpm major changes that can break pnpm i --frozen-lockfile without any repo
changes. This can cause unexpected CI/CD and Docker build failures over time.

Agent Prompt

### Issue description
`frontend/Dockerfile` installs `pnpm@latest`, which makes builds non-reproducible and can break `pnpm i --frozen-lockfile` when pnpm releases a new major/lockfile format.

### Issue Context
The repo has `frontend/pnpm-lock.yaml` with `lockfileVersion: '9.0'` and `frontend/package.json` does not declare a `packageManager` field.

### Fix Focus Areas
- frontend/Dockerfile[1-18]
- frontend/package.json[1-41]

### Suggested fix
Either:
1) Pin pnpm in Dockerfile (e.g., `RUN npm i -g pnpm@<exact_version>`), or
2) Prefer Corepack + pin in `package.json` (add `"packageManager": "pnpm@<exact_version>"`) and use Corepack consistently in build stages.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools