ModernLeft/athena-archive-ci-image
3
0
Fork 0
Code Issues 5 Pull requests 1 Releases Packages 1 Activity Actions

chore: align Dockerfile pnpm pin with vendored packageManager #29

New issue
Open
opened 2026-05-13 06:06:55 +00:00 by gravityfargo · 0 comments
gravityfargo commented 2026-05-13 06:06:55 +00:00
Owner
Copy link

The Dockerfile activates pnpm via corepack at a hard-coded version:

RUN corepack enable \
 && corepack prepare pnpm@10.33.2 --activate

But the vendored package.json declares a different version:

"packageManager": "pnpm@10.33.4"

Why this is harmless today

When CI runs pnpm install inside a project that has a packageManager field, corepack honours the field — it downloads pnpm@10.33.4 to COREPACK_HOME (/opt/corepack, which is persisted in the image) and uses that version, not the 10.33.2 baked in. So the actual install always matches what the FE repo declares.

Why it's still worth fixing

  • The corepack prepare pnpm@10.33.2 --activate line is now a vestigial pin that no longer reflects reality. It also wastes a network round-trip at CI cold-start, because corepack has to fetch 10.33.4 on top of the baked 10.33.2.
  • The image's prefetch step (pnpm install --frozen-lockfile populating /opt/pnpm-store) DOES use the project's packageManager (10.33.4), so the baked store is 10.33.4-shaped. The 10.33.2 pin only fires when something runs pnpm outside a project — unlikely, but a footgun.
  • Renovate already bumps the packageManager field via the FE repo and the manifests get re-vendored here automatically. The Dockerfile pin doesn't move with it, so the gap will keep widening.

Fix options

  1. Drop the version from corepack prepare and let corepack resolve from the project's packageManager at first invocation:

    RUN corepack enable

    This is the cleanest — one source of truth (package.json). Downside: cold-start in the prefetch step pays the corepack download.

  2. Read the version from the vendored package.json at build time so the Dockerfile stays in sync without manual edits:

    ARG PNPM_VERSION
RUN corepack enable \
 && corepack prepare "pnpm@${PNPM_VERSION}" --activate

    …with the build workflow passing --build-arg PNPM_VERSION=$(jq -r '.packageManager | split("@") | .[1]' package.json). More moving parts but no drift.

  3. Just bump the literal to pnpm@10.33.4. Cheapest fix, but the drift will reappear on the next renovate pnpm bump.

Option 1 is probably the right one — the packageManager field is the canonical source and is already what wins at install time.

Observed in

CI-image commit 76bc1b1 bump package json (the manifest bump after the FE landed pnpm@10.33.4 via #219). Image tag sha-76bc1b1 ships this drift; everything earlier shipped 10.33.2 in both places.

The Dockerfile activates pnpm via corepack at a hard-coded version: ```dockerfile RUN corepack enable \ && corepack prepare pnpm@10.33.2 --activate ``` But the vendored `package.json` declares a different version: ```json "packageManager": "pnpm@10.33.4" ``` ## Why this is harmless today When CI runs `pnpm install` inside a project that has a `packageManager` field, corepack honours the field — it downloads `pnpm@10.33.4` to `COREPACK_HOME` (`/opt/corepack`, which is persisted in the image) and uses that version, not the 10.33.2 baked in. So the actual install always matches what the FE repo declares. ## Why it's still worth fixing - The `corepack prepare pnpm@10.33.2 --activate` line is now a vestigial pin that no longer reflects reality. It also wastes a network round-trip at CI cold-start, because corepack has to fetch 10.33.4 on top of the baked 10.33.2. - The image's _prefetch_ step (`pnpm install --frozen-lockfile` populating `/opt/pnpm-store`) DOES use the project's `packageManager` (10.33.4), so the baked store is 10.33.4-shaped. The 10.33.2 pin only fires when something runs `pnpm` _outside_ a project — unlikely, but a footgun. - Renovate already bumps the `packageManager` field via the FE repo and the manifests get re-vendored here automatically. The Dockerfile pin doesn't move with it, so the gap will keep widening. ## Fix options 1. **Drop the version from `corepack prepare`** and let corepack resolve from the project's `packageManager` at first invocation: ```dockerfile RUN corepack enable ``` This is the cleanest — one source of truth (`package.json`). Downside: cold-start in the prefetch step pays the corepack download. 2. **Read the version from the vendored `package.json`** at build time so the Dockerfile stays in sync without manual edits: ```dockerfile ARG PNPM_VERSION RUN corepack enable \ && corepack prepare "pnpm@${PNPM_VERSION}" --activate ``` …with the build workflow passing `--build-arg PNPM_VERSION=$(jq -r '.packageManager | split("@") | .[1]' package.json)`. More moving parts but no drift. 3. **Just bump the literal** to `pnpm@10.33.4`. Cheapest fix, but the drift will reappear on the next renovate pnpm bump. Option 1 is probably the right one — the `packageManager` field is the canonical source and is already what wins at install time. ## Observed in CI-image commit `76bc1b1 bump package json` (the manifest bump after the FE landed `pnpm@10.33.4` via #219). Image tag `sha-76bc1b1` ships this drift; everything earlier shipped 10.33.2 in both places.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
renovate/actions-checkout-7.x
renovate/lock-file-maintenance
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ModernLeft/athena-archive-ci-image#29
No description provided.