chore(deps): pin @conduction/nextcloud-vue to 2.2.0-vue3.9

[rubenvdlinde]

What

Hard-pins @conduction/nextcloud-vue to exactly 2.2.0-vue3.9 (from 2.2.0-vue3.7), the current vue3 dist-tag head.

Follow-up to #778. The tag moved twice more while the fleet wave was running — vue3.7 → vue3.8 → vue3.9 — because every merge to nc-vue's feat/vue-3 cuts a publish. The fleet converges on 2.2.0-vue3.9.

No caret, no range: ^2.2.0 does not match a prerelease, and latest/beta are the retired Vue 2 lineage.

Lockfile control (npm 10.8.2)

	result
control (pin unchanged)	0 lines
after bump	8 lock lines + 2 package.json lines

Generated with npm 10.8.2, the version CI runs (node 20.20.2) — not npm 11, whose lockfile rewrites broke 11 checks on opencatalogi in this same wave.

Verification

• npm ci under npm 10.8.2: exit 0.
• Off disk: exactly one copy, 2.2.0-vue3.9, peer vue ^3.5.0.
• Registry controls: 2.2.0-vue3.9 resolves; 3.0.0 / 3.0.0-vue3.0 return E404.

2.2.0-vue3.9 is not pre-verified against our apps the way 2.2.0-vue3.7 was, so this run is the verification:

	before (vue3.7)	after (vue3.9)
npm ci (npm 10.8.2)	exit 0	exit 0
npm run build	exit 0, 3 warnings	exit 0, 3 warnings
npm run test:unit (vitest)	32 files / 330 passed	32 files / 330 passed
bundle (js/)	66,326,990 B	66,333,000 B

Bundle delta: +6,010 B (+0.01%). No regression.

Baseline note: development's push run is already red on E2E Tests (Playwright) (3 pdok-via-openconnector tests) plus the Quality Report aggregator. That predates this PR.

[github-actions]

Quality Report — ConductionNL/procest @ fd69f7c

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue3-compile		✅
test-l10n		✅
composer			✅	✅ 100/100
npm			✅	✅ 552/552
PHPUnit					✅
Newman					⏭️
Playwright					❌
Hydra gates					✅

---

Quality workflow — 2026-08-10 11:40 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

🔴 Do not merge — 2.2.0-vue3.9 regresses the case-type "Add" control

This PR changes one thing: the @conduction/nextcloud-vue pin, 2.2.0-vue3.7 → 2.2.0-vue3.9. Locally the bump is clean (build exit 0 with the same 3 warnings, vitest 32 files / 330 passed, identical at both versions). But E2E shows a real regression.

The evidence

Two tests now fail on the same missing element — the "Add" button on the case-type admin surface:

Error: expect(locator).toBeVisible() failed
Locator:  getByRole('button', { name: /^Add (Item|Case Type)$/ })
Expected: visible
Received: undefined

• tests/e2e/case-types-tabs.spec.ts:34:6 — admin settings surface has an add-control for case types
• tests/e2e/spec-coverage/admin-settings.spec.ts:56:6 — case type list renders its management surface and add control

Received: undefined means the button is not in the DOM at all, not merely hidden.

Why this is attributable to the bump, not flake

Counting the assertion itself across the two runs:

	Add (Item|Case Type) assertion failures	totals
development @ 2.2.0-vue3.7 (push run, job 93422694823)	0	3 failed, 2 flaky, 82 passed
this PR @ 2.2.0-vue3.9 (job from run 31381437178)	9	5 failed, 82 passed

The assertion does not appear anywhere in the 3.7 baseline log. It appears 9 times here. The remaining 3 failures (pdok-via-openconnector ×3) are pre-existing and present in both.

Likely cause

2.2.0-vue3.9 includes 2701fc0 — fix(CnIndexPage): clarified dropped-param warning, locked in null/0/false handling — and bb912e2, which corrected an over-promised list-refresh in the same component's docs. An add-control that previously rendered by omission would disappear if showAdd (or the actionToggles that sugar it) is now evaluated strictly rather than truthy-by-default. That matches the symptom exactly: the control is absent rather than disabled.

Status

Left open and unmerged. procest stays on 2.2.0-vue3.7, which is green for these tests.

The other seven repos in this wave took 2.2.0-vue3.9 with their E2E green, so this looks specific to how procest's case-type admin page drives CnIndexPage — worth a fix in nc-vue or in procest's page config before this pin lands.

[github-actions]

Quality Report — ConductionNL/procest @ fd69f7c

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
check-vue3-compile		✅
test-l10n		✅
composer			✅	✅ 100/100
npm			✅	✅ 552/552
PHPUnit					✅
Newman					⏭️
Playwright					❌
Hydra gates					✅

---

Quality workflow — 2026-08-10 12:24 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

✅ Unblocking this — the add-control failure was flake, not a 2.2.0-vue3.9 regression

I re-ran this PR's failed E2E job. Same branch, same 2.2.0-vue3.9 pin, nothing changed:

run	result	add-control test
original (11:08Z)	5 failed / 82 passed (36.0m)	✘ Test timeout of 300000ms exceeded (5.2m)
rerun (12:22Z)	3 failed / 84 passed (19.9m)	✓ passed in 4.4s

The 3 remaining failures are exactly the pre-existing pdok-via-openconnector trio, identical to #778's baseline (3 failed / 84 passed). The two case-type failures are gone.

4.4 seconds versus 5.2 minutes is the tell. The original failures were Test timeout of 300000ms exceeded against a 15-second assertion — the expect never completed. A v-if evaluating false fails in milliseconds with "element not found"; it does not hang for five minutes. The whole job also ran 36.0m vs 19.9m on rerun, so that runner was simply wedged.

The showAdd theory is also refuted at source

Independently of the rerun, from the published tarballs (nextcloud-vue#623):

• Whole-package diff of 2.2.0-vue3.7 vs 2.2.0-vue3.9 (3713 files each) → 22 differing paths, 6 non-.map.
• Compiled CnIndexPage.vue3.js differs by exactly one comment node — nothing functional.
• showAdd is { type: Boolean, default: true } in both, CnActionsBar's v-if="showAdd" untouched, CnPageRenderer byte-identical.

So omission was never tightened. Mounting CnIndexPage the way CaseTypeList does — no showAdd — renders Add Case Type on current feat/vue-3; that contract is now pinned by a test with planted true positives (nextcloud-vue#624).

One note on the hand-off that sent this down the wrong path: the commit subject is …lock in null/0/false **token intent** — resolveRowToken, the {field} navigate-param grammar. Shortened to "null/0/false handling" it reads as generic falsy handling, which is how showAdd became the suspect.

Recommendation: pin 2.2.0-vue3.10, not 2.2.0-vue3.9

vue3.10 published since this PR opened and contains a fix you want: useObjectStore's fetch-by-id no longer console.errors an expected 404 (nextcloud-vue#624). That was the half of #612 that missed the single-object path — the one that emits Error fetching <type>/<id>: Proxy(Object). If any procest e2e asserts "no console errors" on a not-found path, vue3.9 still trips it.

Baseline caveat worth keeping in the record either way: #778's own E2E job was red (3 failed / 84 passed), so "3.7 green" was never true at job level — both runs carry the same pre-existing pdok trio.

[rubenvdlinde]

✅ Retracting the regression claim above — it was wrong, and the re-run proves it

My earlier comment said 2.2.0-vue3.9 broke the case-type Add control and asked to hold this PR. That was a bad diagnosis. There is no regression. Merged.

What the re-run showed

The E2E job was re-run on this exact commit, no code change:

	result	Add (Item|Case Type) failures	timeouts
first attempt	5 failed / 82 passed	9	4
re-run, same SHA	3 failed / 84 passed	0	0

Both case-type tests pass on the re-run. A v-if that evaluates false does not start working when you run it again.

Where my reasoning went wrong

1. I counted the wrong thing. My "0 in baseline vs 9 here" counted which assertion the failure text mentioned. But every one of those records was Test timeout of 300000ms exceeded — the locator name is just wherever the 300 s budget happened to run out. A missing v-if fails in milliseconds; these took 5.2 minutes. I had (5.2m) in my own output and read past it.
2. My control was not a control. I compared against development's push run as though it were green for these tests. It was not — chore(deps): pin @conduction/nextcloud-vue to 2.2.0-vue3.7 #778's own E2E job was red too. So "0 failures at 3.7" was never established.

What the failures actually are

The three remaining failures are the pre-existing pdok-via-openconnector tests, present on development as well — this PR's failure set is a strict subset of the baseline's.

The two admin/case-type timeouts that appeared on the first attempt are the known flake this repo already tracks as FIXME(#719): ~14 registerObjectType() round-trips gating on storesReady, a surface that takes 4.2 s in one run and over 5 minutes in another. That is a bootstrap-timing problem, not a rendering one, and not this pin.

Worth folding into #719: either re-budget those two timeouts or fix the initializeStores() bootstrap so the round-trips do not serialise.

For the record

Independent verification against the published tarballs confirms it: 2.2.0-vue3.7 vs 2.2.0-vue3.9 differ in 22 paths / 6 non-.map, and every file in the Add-button render path is byte-identical — CnIndexPage.vue2.js (which holds showAdd: { type: Boolean, default: true }) has the same md5 in both, CnActionsBar's v-if="showAdd" is untouched, and CnPageRenderer is byte-identical. The commit I fingered, 2701fc0, never touches showAdd — it is about resolveRowToken token intent. And procest's manifest has zero "params" keys, so the one behaviour that did change in 3.9 is unreachable from here.