What happened
release-selfhost.yml's multi-arch Docker build started failing on every subsequent beta release attempt with:
```
npm error code EOVERRIDE
npm error Override for sharp@0.34.5 conflicts with direct dependency
```
Root cause
`Dockerfile` hardcodes `RUN npm install sharp@0.34.5 --ignore-scripts` (a separate, standalone install outside the main `npm ci`, needed because esbuild marks `sharp` external in the self-host bundle). `chore(deps): update dependency sharp to ^0.35.0 [security] (#7970)` later bumped `package.json`'s `sharp` dependency AND added a matching `overrides.sharp: "^0.35.0"` entry — but a Dependabot-style dependency bump only touches `package.json`/`package-lock.json`, never a hardcoded version string inside a Dockerfile `RUN` command, so this line silently drifted out of sync.
The failure isn't simply "the pinned version is stale" — even re-pinning the Dockerfile to the exact resolved version (`sharp@0.35.3`) still fails with the same `EOVERRIDE` error. Recent npm treats an explicit `npm install @` command-line install and an `overrides` entry for the same package as two competing authorities and refuses to silently pick one — regardless of whether the versions actually agree.
Fix
Made the Dockerfile's sharp install unversioned (`npm install sharp --ignore-scripts`), letting it resolve from `package.json`'s `overrides` entry (the actual source of truth, already kept current by Dependabot/Renovate) instead of a second, independently-hardcoded pin that has no mechanism to stay in sync.
Follow-up (not done here — flagging for later)
No CI check currently catches this drift class (a Dockerfile-embedded npm install argument silently diverging from package.json). Worth a lightweight drift-check script (mirroring the many existing `*-drift-check` scripts in this repo) if a similar hardcoded-version-in-Dockerfile pattern is added again in the future — but the actual fix here (going unversioned) removes the drift vector entirely for this specific line, so this is optional hardening, not required follow-up.
What happened
release-selfhost.yml's multi-arch Docker build started failing on every subsequent beta release attempt with:```
npm error code EOVERRIDE
npm error Override for sharp@0.34.5 conflicts with direct dependency
```
Root cause
`Dockerfile` hardcodes `RUN npm install sharp@0.34.5 --ignore-scripts` (a separate, standalone install outside the main `npm ci`, needed because esbuild marks `sharp` external in the self-host bundle). `chore(deps): update dependency sharp to ^0.35.0 [security] (#7970)` later bumped `package.json`'s `sharp` dependency AND added a matching `overrides.sharp: "^0.35.0"` entry — but a Dependabot-style dependency bump only touches `package.json`/`package-lock.json`, never a hardcoded version string inside a Dockerfile `RUN` command, so this line silently drifted out of sync.
The failure isn't simply "the pinned version is stale" — even re-pinning the Dockerfile to the exact resolved version (`sharp@0.35.3`) still fails with the same `EOVERRIDE` error. Recent npm treats an explicit `npm install @` command-line install and an `overrides` entry for the same package as two competing authorities and refuses to silently pick one — regardless of whether the versions actually agree.
Fix
Made the Dockerfile's sharp install unversioned (`npm install sharp --ignore-scripts`), letting it resolve from `package.json`'s `overrides` entry (the actual source of truth, already kept current by Dependabot/Renovate) instead of a second, independently-hardcoded pin that has no mechanism to stay in sync.
Follow-up (not done here — flagging for later)
No CI check currently catches this drift class (a Dockerfile-embedded npm install argument silently diverging from package.json). Worth a lightweight drift-check script (mirroring the many existing `*-drift-check` scripts in this repo) if a similar hardcoded-version-in-Dockerfile pattern is added again in the future — but the actual fix here (going unversioned) removes the drift vector entirely for this specific line, so this is optional hardening, not required follow-up.