The main to development sync can desync package.json from package-lock.json

[rubenvdlinde]

Measured 2026-09-12 across all 21 core apps, with npm ci itself rather than a proxy, on the toolchain quality.yml pins (Node 24.11.1, npm 11.19.1) and with each repo's own .npmrc present.

branch	result
main, all 21	all 21 exit 0
development, all 21	decidiq and shillinq fail EUSAGE, the other 19 exit 0

The desync is created by the sync merge, not by the dependency bumps. main is clean everywhere, including on the two broken apps. The main to beta to development merge took main's package.json and kept development's package-lock.json. Neither side is individually wrong, and the merge has no conflict to report, because the two files are separate paths. Git has no reason to complain and npm has every reason to.

What it costs. One broken install reads as sixteen failing jobs on decidiq and twenty-three on shillinq: eslint, stylelint, build, l10n, unit tests, npm audit, licence, gates. Every one of them is npm ci dying at step one. It also blocks every open PR in the repo, because GitHub Actions checks out the merge of head into base for pull_request events, so each PR inherits the broken base through no fault of its own.

Why a repair cannot just take main's lock. development is legitimately ahead of main on ranges of its own: decidiq carries vite ^8.2.2, vitest ^5.0.0 and webpack ^5.110.3; shillinq carries @conduction/nextcloud-vue ^2.39.0 and @nextcloud/axios ~2.6.0. The lock has to be regenerated against the manifest actually on development (npm install --package-lock-only), which is what the two repairs did: decidiq#1300 and shillinq#1591, both verified with npm ci from a deleted node_modules.

Two things worth fixing here rather than app by app:

1. A lockfile-sync check that runs in seconds. npm ci --dry-run, or equivalent, on every PR and on every sync. It catches this exact failure before it reaches a branch everyone builds on, and it is far cheaper than the sixteen jobs currently discovering it one at a time.
2. The sync workflow should regenerate the lock when it carries a package.json across, or refuse and open an issue. Carrying one half of a pair is the defect.

A measurement note for anyone checking fleet health. Most apps' newest Code Quality run on development reads conclusion: skipped. That is not a dark gate: those are pull_request runs whose head branch is development, which the workflow's if: deliberately excludes. The real signal is the event=push run. Two separate readings of this were wrong today before the right query was found, and skipped looks very close to passed on a dashboard.

[rubenvdlinde]

The lockfile-sync check is open as #767, shipped as a warning rather than a gate.

Re-measured after the two repairs, with npm ci --dry-run itself rather than a proxy, on the toolchain pins (Node 24.11.1, npm 11.19.1) and with each repo's own .npmrc present:

branch	result
development, all 21 core apps	21 of 21 pass
beta, all 21 core apps	21 of 21 pass

So the would-fail count for a blocking version is zero today. decidiq and shillinq are clean at their current tips (decidiq#1300, shillinq#1591 landed).

It is still landing non-blocking. All 21 apps resolve the shared workflow at @main, so a gate merged as blocking fails every affected repo the same minute, and "zero today" is a measurement with a timestamp, not a property. lockfile-sync-blocking: true flips it per repo once that repo is re-measured.

A note on the instrument, because it nearly produced a phantom. Run this on the pins or not at all. Local npm 10.8.2 without the repo .npmrc gives a different, unrelated ERESOLVE on at least one repo, and ten of the 21 carry legacy-peer-deps=true while min-release-age exists only in npm 11. A lane chasing that error would have been debugging a dependency that is not broken.

Positive control. The check was run against decidiq at 69971ec, the commit before the repair: it classifies as a desync. Against decidiq development today: the two files agree. Against a tree with a package.json and no lockfile: no verdict, deliberately not a finding, because npm answers EUSAGE for that case too and a code on its own is not a diagnosis.

The second half of this issue, making the sync workflow regenerate the lock when it carries a package.json across, is not in #767.