chore: update to pnpm v12

[SamTV12345]

No description provided.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Upgrade project tooling to pnpm 12.4.2

⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Raises the project pnpm requirement and package-manager pin to pnpm 12.4.2.
• Aligns Docker and Snap builds with the project pnpm version.
• Locks pnpm platform executables and refreshes version-specific guidance.

Diagram

graph TD
  P["pnpm 12.4.2"] --> M["Project Metadata"] --> L["Dependency Lockfile"]
  M --> D["Docker Images"] --> G["Offline Guard"]
  M --> S["Snap Package"]
  M --> C["CI Release"]

Loading

High-Level Assessment

The explicit version alignment is appropriate because package.json, Docker, and Snap bootstrap pnpm in different environments. Deriving every version dynamically from package.json was considered, but build-stage ordering and packaging isolation would add complexity; retaining the Docker offline fallback also safely handles future drift.

Files changed (9) +186 / -30

Tests (1) +6 / -6

dockerfilePnpmPin.tsRefresh Docker pnpm pin regression rationale +6/-6

Refresh Docker pnpm pin regression rationale

• Updates test documentation to reflect that Docker and package.json now use the same pnpm version. The existing assertions continue protecting offline startup if those versions drift later.

src/tests/backend/specs/dockerfilePnpmPin.ts

Documentation (4) +4 / -4

docker.ymlGeneralize Docker regression guidance beyond pnpm 11 +1/-1

Generalize Docker regression guidance beyond pnpm 11

• Removes the obsolete pnpm 11 qualifier from the named-volume startup regression documentation. Workflow behavior is unchanged.

.github/workflows/docker.yml

release.ymlGeneralize release build-script guidance +1/-1

Generalize release build-script guidance

• Updates the Sharp installation comment to describe current pnpm behavior without tying it to version 11. Release workflow behavior remains unchanged.

.github/workflows/release.yml

release.tsRemove obsolete pnpm version qualifier +1/-1

Remove obsolete pnpm version qualifier

• Generalizes the explanation for using jq instead of 'pnpm version' on a dirty documentation repository. Release behavior is unchanged.

bin/release.ts

README.mdDocument pnpm 12 packaging prerequisite +1/-1

Document pnpm 12 packaging prerequisite

• Updates local package-building prerequisites to require pnpm 12 or newer.

packaging/README.md

Other (4) +176 / -20

DockerfileAlign container builds with pnpm 12.4.2 +15/-17

Align container builds with pnpm 12.4.2

• Updates the container pnpm build argument to 12.4.2, matching package.json. Revises guidance to explain that minimum-release-age exclusions now permit version alignment while the offline self-provisioning fallback remains enabled.

Dockerfile

package.jsonRequire and pin pnpm 12 +2/-2

Require and pin pnpm 12

• Raises the supported pnpm engine floor to 12.0.0 and pins package-manager provisioning to pnpm 12.4.2.

package.json

pnpm-lock.yamlLock pnpm 12.4.2 platform executables +158/-0

Lock pnpm 12.4.2 platform executables

• Adds the pnpm 12.4.2 package-manager dependency and locks its optional executables for supported operating systems and architectures. Existing workspace dependency data remains in the lockfile.

pnpm-lock.yaml

snapcraft.yamlBuild Snap packages with pnpm 12.4.2 +1/-1

Build Snap packages with pnpm 12.4.2

• Changes the Corepack preparation step to activate pnpm 12.4.2, aligning Snap builds with the project pin.

snap/snapcraft.yaml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. All dependency installs fail 🐞 Bug ≡ Correctness

Description

pnpm-lock.yaml starts a second YAML document at line 158 instead of merging the new
package-manager dependency into the existing lockfile. Any pnpm install that reads the root lockfile
fails during parsing, including frozen CI installs and the Docker build before tests or compilation
can run.

Code

pnpm-lock.yaml[158]

+---

Evidence

The first document contains only the root package-manager dependency, while line 158 starts another
document containing the actual workspace settings and dependencies. Repository CI and Docker paths
invoke pnpm install against this root file, so the malformed stream prevents all of those paths from
progressing.

pnpm-lock.yaml[1-11]
pnpm-lock.yaml[158-165]
.github/workflows/backend-tests.yml[42-59]
.github/workflows/frontend-tests.yml[38-49]
Dockerfile[24-30]

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 committed `pnpm-lock.yaml` contains two YAML documents: a new document containing only pnpm 12.4.2 metadata followed by the original project lockfile. pnpm expects a single lockfile document, so dependency installation fails before resolution.
## Fix Focus Areas
- pnpm-lock.yaml[1-4]
- pnpm-lock.yaml[158-161]
## Recommended Fix
Regenerate `pnpm-lock.yaml` with pnpm 12.4.2 as one document. Preserve the existing workspace importers, settings, overrides, packages, and snapshots while merging any required `packageManagerDependencies` entry into that same lockfile structure; remove the extra document separators.

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

---

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. All dependency installs fail 🐞 Bug ≡ Correctness

pnpm-lock.yaml starts a second YAML document at line 158 instead of merging the new
package-manager dependency into the existing lockfile. Any pnpm install that reads the root lockfile
fails during parsing, including frozen CI installs and the Docker build before tests or compilation
can run.

Agent Prompt

## Issue description
The committed `pnpm-lock.yaml` contains two YAML documents: a new document containing only pnpm 12.4.2 metadata followed by the original project lockfile. pnpm expects a single lockfile document, so dependency installation fails before resolution.

## Fix Focus Areas
- pnpm-lock.yaml[1-4]
- pnpm-lock.yaml[158-161]

## Recommended Fix
Regenerate `pnpm-lock.yaml` with pnpm 12.4.2 as one document. Preserve the existing workspace importers, settings, overrides, packages, and snapshots while merging any required `packageManagerDependencies` entry into that same lockfile structure; remove the extra document separators.

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