chore(dependabot): hold back vue-router 5 as well - #1027
Merged
Conversation
…n install
Installing this app planted 334 objects nobody asked for.
SettingsService::loadConfiguration() merges decidesk_register.json with all 26
register.d fragments, and every one of them carried its own
x-openregister.seedData.objects. The InitializeSettings repair step runs that
merge, so a fresh install seeded a Gemeenteraad Amsterdam, a VvE Zeewaarts, a
pub quiz, five ACME B.V. bodies and eight placeholder TOOI mappings into the
operator's register. A municipality got the VvE data. A VvE got the council
data. Nobody chose any of it.
The wizard meanwhile offered a DIFFERENT dataset, whose own step text said
"Skip this on a production install". By the time an operator read that
sentence, 334 objects were already in their register.
So the fragments now declare schemas only, and the objects live in
lib/Settings/profiles/, one file per example set. A bare install plants
nothing; the wizard asks which organisation this is for, and loads that.
## The split had to be a closure, not a partition
The seeds cross-reference each other by slug. The reference graph has one
connected component of 170 objects tangling municipal, corporate and
association bodies together, so no partition exists. Each set is instead
anchored on its governance bodies and closed over outbound references, so every
reference resolves inside the set carrying it. Sets may overlap, and 15 objects
do. Verified: 334 of 334 classified, zero dangling references, zero orphans.
## Why the descriptor declares no register
An example set carries @self.configuration/register/schema on every object and
declares NO components.registers. That is load-bearing.
ImportHandler::importRegister() calls setApplication($appId) unconditionally
when it updates an existing register, so a descriptor that declared decidiq
would re-point the register at the profile's config id and hydrate over its
authorization block: the baseline that stops any authenticated user rewriting
another body's decisions.
Verified on a live instance: importing this shape left application=decidiq, the
version and the authorization hash byte-identical, imported 45 objects, and
added nothing on a second run.
The files sit in a SUBDIRECTORY because RegisterDescriptorService scans
lib/Settings/*.json non-recursively and indexes by declared register slug; four
profiles in lib/Settings would collide with each other and with the app's own
register.
## Two wizard steps, because an action carries no body
CnSetupWizard::runAction() posts to /api/setup/action/{action} with no body, so
an action cannot carry the answer. A choice step records which set via the new
POST /api/setup/config, and the run-action step reads it back. ADR-111 keeps
the schema-generated mock on offer, so it is one option in the same choice
rather than a second question about the same thing.
## Ten pre-existing defects this surfaced, all fixed
Validating every seed against its schema found:
- Three seeds keyed on `regulation`, which is not a decidiq schema slug: the
app's is `regeling`. Because importSeedData() resolves a slug cross-app with
multitenancy off, `regulation` resolves to LEARNIQ's schema.
- Regeling.status was required and named by x-openregister-lifecycle, but never
declared as a property, so OpenRegister created no magic-table column.
Measured: oc_openregister_table_21_262 carried every other property and no
status column, which means the declared in-preparation -> adopted ->
in-effect -> lapsed map could never advance a regulation.
- Six invalid enum values on the pub-quiz decision-stage seeds.
- Two governance bodies missing the required `domain`.
- The works-council seeds described a city council: all three WOR consultation
requests carried governanceBody: gemeenteraad-amsterdam, a null-UUID
director, and a raadsvergadering as their overlegvergadering. Replaced with a
real 45-object set built around an ondernemingsraad at ACME B.V.
## Verification
1235 PHP unit tests and 378 vitest tests pass. PHPCS 0 errors, PHPMD, PHPStan
and Psalm clean. Manifest validates against schema 2.26.0. The manifest-drift
guard was proved to FAIL when the manifest and the shipped sets disagree.
Two hydra gates (22, 53) still fail, and did before this change: hydra-gates
v1.10.0 vendors manifest schema 2.25.0, which predates the `flow` page type
that FlowDetail already used. That is fleet debt in ConductionNL/.github.
vue-router 5 peers `vite: ^7.3.0 || ^8.0.0` and expects a Vite toolchain. These apps build with webpack, which cannot resolve it at all: the build dies on `Can't resolve 'vue-router'` from src and from @nextcloud/vue's own chunks. Adopting it is a Vite migration, not a version bump. Dependabot proposed it across 8 repositories in a single run, and merging any one of them takes that app's build from green to red with no code change that can fix it. versioniq already builds with Vite and is the natural pilot if the fleet does move. Lift this when an app's toolchain can actually take it.
rubenvdlinde
requested review from
Rem-Dam,
SudoThijn,
WilcoLouwerse,
bbrands02,
remko48 and
rjzondervan
as code owners
August 30, 2026 20:32
Contributor
Quality Report — ConductionNL/decidiq @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| check-nav-ceiling | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ❌ | ||||
| check-l10n-js | ❌ | ||||
| check-schema-l10n | ❌ | ||||
| composer | ✅ | ✅ 104/104 | |||
| npm | ✅ | ✅ 557/557 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ❌ | ||||
| Newman | ❌ | ||||
| Playwright | 🚨 NO VERDICT — enabled but never ran | ||||
| Hydra gates | ❌ |
Quality workflow — 2026-08-30 23:32 UTC
Download the full PDF report from the workflow artifacts.
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
2 participants
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.
vue-router 5 peers
vite: ^7.3.0 || ^8.0.0and expects a Vite toolchain. These apps build with webpack, which cannot resolve it at all — the build dies onCan't resolve 'vue-router'fromsrcand from@nextcloud/vue's own chunks. Adopting it is a Vite migration, not a version bump.Dependabot proposed it across 8 repositories in a single run, and merging any one takes that app's build from green to red with no code change in the repository that can fix it.
versioniq already builds with Vite and is the natural pilot if the fleet does move. Lift this when an app's toolchain can actually take it.