Skip to content

fix(deps): pin next to ^16.3.1 (was open-ended >=16.3.1) - #68

Merged
acamarata merged 2 commits into
mainfrom
fix/admin-build-hardening
Aug 15, 2026
Merged

fix(deps): pin next to ^16.3.1 (was open-ended >=16.3.1)#68
acamarata merged 2 commits into
mainfrom
fix/admin-build-hardening

Conversation

@acamarata

Copy link
Copy Markdown
Collaborator

"next": ">=16.3.1" has no upper bound — any future major release gets pulled silently on the next lockfile refresh, landing a framework major in production unreviewed. Pinned to the 16.x line.

Context (and a correction to the reported diagnosis)

Found while investigating the two 46-minute admin production builds that errored on Vercel.

The build is healthy. A clean local pnpm build (next build --webpack) completes in 112s, exit 0. There is no hanging step in the build chain — dev and test:watch exist but are not invoked by build, and there are no build-time network fetches.

So the 46-minute hangs are environmental (Vercel build-resource contention / stuck queued deployments — consistent with the report's own observation that two deployments were still Building at 20+ minutes while a newer one had already gone Ready), not a build-config defect. Adding a build timeout would mask the symptom rather than fix it; that belongs in Vercel-side investigation.

This pin is a separate, genuine supply-chain risk surfaced by that investigation.

'next': '>=16.3.1' has no upper bound, so any future MAJOR release would be
pulled silently on the next lockfile refresh — a framework major landing
unreviewed in production. Pinned to the 16.x line.

Context: filed while investigating two 46-minute admin production builds that
errored on Vercel. The build itself is healthy — a clean local
'pnpm build' (next build --webpack) completes in 112s with exit 0 — so the
46-minute hangs are environmental (Vercel build-resource contention / stuck
queued deployments), NOT a build-config defect. This pin is a separate, real
supply-chain risk found during that investigation.
Changing package.json's next range without refreshing the lockfile left the two
out of sync, so 'pnpm install --frozen-lockfile' failed the CI jobs with:
  specifiers in the lockfile don't match specifiers in package.json
    - next (lockfile: >=16.3.1, manifest: ^16.3.1)

Regenerated with --lockfile-only. The RESOLVED version is unchanged (16.3.1) —
only the recorded specifier moves — so this carries no dependency-graph risk.
Verified: pnpm install --frozen-lockfile now succeeds.
@acamarata
acamarata merged commit d4491a4 into main Aug 15, 2026
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant