typescript-lockfile-npm-ci-desync

Answer 1

Root cause. The repo has a pnpm-first workflow (package.json + pnpm-lock.yaml) but its CI runs npm ci, which is strict: it never mutates package-lock.json and refuses to run if package.json and package-lock.json disagree. COV-001 used pnpm add -D @vitest/coverage-v8 (updates package.json + pnpm-lock.yaml only), leaving package-lock.json stale. npm ci then aborts with EUSAGE and a "Missing from lock file" list of the new dep and every transitive package it introduces.

Fix — regenerate the npm lockfile from the (already correct) package.json, without touching node_modules, the pnpm lockfile, or the dependency versions:

# after any pnpm add/remove that changed package.json:
npm install --package-lock-only --no-audit --no-fund
git add package-lock.json
git commit -m "chore: sync package-lock.json with package.json (COV-001)"
git push

# verify locally before pushing:
rm -rf node_modules && npm ci          # must exit 0

--package-lock-only resolves only the missing subgraph and appends it — the diff is purely additive (0 deletions), lockfileVersion stays 3, and ranges already in the lockfile are not re-resolved.

Prevent recurrence — guard both lockfiles in CI (or a pre-commit hook). The failure mode is asymmetric: you must check the lockfile the CI actually consumes plus the one the dev workflow produces:

#!/usr/bin/env bash
# ci/check-lockfiles.sh — fail if package.json deps are missing from either lockfile
set -euo pipefail
cd "${1:-.}"
for lf in package-lock.json pnpm-lock.yaml; do
  [ -f "$lf" ] || { echo "MISSING $lf"; exit 1; }
  node - "$lf" <<'NODE'
const fs = require('fs');
const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));
const deps = { ...pkg.dependencies, ...pkg.devDependencies, ...(pkg.peerDependencies||{}) };
const raw = fs.readFileSync(process.argv[2], 'utf8');
const all = new Set();
if (process.argv[2].endsWith('package-lock.json')) {
  const lock = JSON.parse(raw);
  if (lock.lockfileVersion === 3) {
    for (const p of Object.keys(lock.packages)) {
      if (!p.startsWith('node_modules/')) continue;
      const parts = p.split('/');
      all.add(parts[1].startsWith('@') ? `${parts[1]}/${parts[2]}` : parts[1]); // scoped pkgs
    }
  } else {
    for (const [name] of Object.entries(lock.dependencies)) all.add(name);
  }
} else {
  // pnpm-lock.yaml v9: root importer dep keys sit at 6-space indent
  const re = /^ {6}['"]?((?:@[^'"\s:]+\/)?[^'"\s:]+)['"]?:/gm;
  let m;
  while ((m = re.exec(raw))) all.add(m[1]);
}
const missing = Object.keys(deps).filter(d => !all.has(d));
if (missing.length) {
  console.error(`[guard:${process.argv[2]}] MISSING from lock file: ${missing.join(', ')}`);
  process.exit(1);
}
console.log(`[guard:${process.argv[2]}] OK — ${Object.keys(deps).length} deps in sync`);
NODE
done
EOF

Process rule: whenever a dependency is added to a pnpm project with npm-based CI, both lockfiles must be committed in the same PR — regenerate with npm install --package-lock-only, never by editing the lockfile by hand.

Answer 2

Three stacked issues surfaced sequentially once the lockfile desync was repaired. Fixes, in the order the test pipeline exposes them:

1. Lockfile desync — npm ci EUSAGE Missing package from lock file

package.json + pnpm-lock.yaml had moved ahead (new @aws-sdk/* deps), but package-lock.json was stale because npm's lockfile had never been regenerated. npm ci refuses to install when the two are out of sync. Regenerate the npm lockfile without touching node_modules:

# pure additive: updates only package-lock.json (+396 lines in the real repo, 0 removals)
npm install --package-lock-only

Then verify before pushing to the Dockerfile path:

npm ci --dry-run        # must exit 0
git diff --stat package-lock.json   # confirm: purely additive, no dependency downgrades

2. Masked docker-build issue — EACCES from 600-mode files + namespaces/ not ignored

The build context (COPY . .) was shipping local 600-mode state/credential files and a namespaces/ directory into the image. Docker COPY preserves host file modes, and image builds run as root, so a host 0600 file becomes root:root 0600 in the image — the runtime USER node (uid 1000) then gets EACCES on read. Add .dockerignore:

node_modules/
namespaces/
*.pem
secrets/
config/creds.json

Also normalize modes on the host (e.g. chmod 644 for non-secret generated state files) so anything that legitimately ships stays world-readable.

3. ssh-tunnel test — Too many authentication failures (agent key flood > MaxAuthTries 6)

CI hosts accumulate dozens of keys in the ssh-agent (deploy keys, rotated creds). The tunnel test's plain ssh -L ... offers every agent key in turn; the target sshd (default MaxAuthTries 6) kills the connection before password auth is ever reached. Pin the tunnel command to a single auth path:

ssh -L 5432:db.internal:5432 \
    -o IdentitiesOnly=yes \
    -o PreferredAuthentications=password \
    <email>

IdentitiesOnly=yes stops the agent flood (only explicit -i/IdentityFile keys are offered); PreferredAuthentications=password jumps straight to the password method.