fix(fleet-bump): honour engines.npm per app + guard a re-resolved lock - #534
Merged
Conversation
…esolved lock
The first real run of this workflow (docudesk PR #710) produced an 84-add /
16-delete package-lock diff for what is a 3-line version bump.
MEASURED, both directions, on that exact pair of lockfiles:
npm 10 (what setup-node bundles with Node 22):
packages added 0, removed 0 -- but 81 `@esbuild/*` platform binaries
newly marked `"dev": true`, while `esbuild` itself stayed unflagged.
npm 11 (what every sampled app declares, `engines.npm: ^11.0.0`):
packages added 0, removed 0, dev-flag changes 0, diff exactly +3/-3.
So the tree never changed; npm 10 simply classifies it differently. This is
the same trap release.yml already documented and fixed in #525 -- setup-node
installs the npm BUNDLED WITH NODE, not the one the repo asks for. release.yml
reads ./package.json once because it runs inside one repo; this workflow walks
21, so the range is re-read and re-honoured inside the loop, with the global
install cached per distinct range (one install for the fleet as it stands).
Adds a second, independent check so a wrong toolchain cannot quietly ship
again: a lock-only bump of ONE package must not add packages, remove packages,
or flip an unrelated package's `dev` flag. If it does, the tree was
re-resolved rather than nudged -- the npm side is reverted and annotated
rather than opened as a PR nobody can review. Verified to FAIL on the known-bad
lock (81 flips) and to PASS on the correct one (0 flips), so it is a check that
demonstrably can fail.
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first real run of
fleet-shared-dep-bump.yml(docudesk #710) produced an 84-add / 16-deletepackage-lock.jsondiff for what should be a 3-line version bump.Measured, both directions, on that exact lockfile pair
devflag flipsThe dependency tree never changed. npm 10 just classifies it differently: 81
@esbuild/*platform binaries gained"dev": true, whileesbuilditself stayed unflagged.Every app sampled — docudesk, launchpad, portaliq, openregister, hermiq, pipelinq, nldesign — declares
engines.npm: ^11.0.0.Why it slipped through
This is the trap
release.ymlalready hit and fixed in #525: setup-node installs the npm bundled with Node, not the one the repo asks for.release.ymlreads./package.jsononce because it runs inside a single repo. This workflow walks 21, so the range has to be re-read and re-honoured inside the loop. The global install is cached per distinct range, so the fleet as it stands costs onenpm i -g.Second, independent check
Fixing the toolchain alone would leave nothing to catch the next variant. So: a lock-only bump of one package must not add packages, remove packages, or flip an unrelated package's
devflag. If it does, the tree was re-resolved rather than nudged — the npm side is reverted and annotated instead of opening a PR nobody can review. The composer bump still proceeds.Both controls exercised, so this is a check that demonstrably can fail:
docudesk #710 will be closed and re-cut once this lands.