eslint 10: four autofixes withheld fleet-wide — each needs its own migration

[rubenvdlinde]

The fleet is now on eslint 10 + @nextcloud/eslint-config@9 (18 repos, all merged). Four rules had their autofix withheld during that migration because their fixes change meaning, not layout. Each is still enabled at its configured severity and every violation is recorded in eslint-suppressions.json, so the debt is counted and any new occurrence fails the run.

Each needs its own migration PR per app. They are listed here in the order they are safe to do.

1. @nextcloud/l10n-enforce-ellipsis — rewrites a translation KEY

Turns 'Loading...' into 'Loading…' inside a translatable string. The string is the key, so the fix orphans every l10n/*.json entry for it. On openconnector one such string appears in 38 locale files; applying the fix in source alone turned test:l10n red while it was green on development.

Migration: move the source string and all locale files in one commit. ~470 occurrences fleet-wide (openregister 128, procest 91, opencatalogi 43, pipelinq 38, scholiq 25, shillinq 19, docudesk 12, openbuild 8, decidesk 6, doriath 6, openconnector 2).

2. @nextcloud/l10n-non-breaking-space — same problem, invisibly

Replaces the ordinary space before … with U+00A0 inside translatable strings. Same key-orphaning effect, but you cannot see it in a diff.

🔑 Worth knowing: the l10n checker reported identical totals on both branches — same file count, same distinct-key count, same en.json size — and still disagreed on pass/fail. The only difference was two bytes inside one key, found by comparing the line as hex. A count that matches is not content that matches.

3. @nextcloud/no-deprecated-library-props — changes rendered DOM

@nextcloud/vue v9 repurposed NcButton's type as the native button type and moved the visual style to variant. The autofix rewrites type="primary" → variant="primary", which is correct — but it changes the rendered markup, and tests assert on it: openbuild lost 10 tests on button[data-nc-button-type="primary"] returning undefined (1375/1375 pass on development).

Migration: rename plus the test updates, together. ~820 occurrences (procest 318, openbuild 164, hermiq 155, openconnector 104, launchpad 79, openregister/shillinq 1 each).

4. vue/prefer-define-options — breaks the build outright

Rewrites export default {…} in a plain <script> block into defineOptions({…}) inside <script setup>, carrying props/data/computed/methods across the block boundary. @vue/compiler-sfc then rejects the result:

[@vue/compiler-sfc] defineOptions() cannot be used to declare props. Use defineProps() instead.

It hit 20 components in softwarecatalog and 15 in docudesk — the two apps that pair <script setup> with a second <script> block. This is a semantic refactor, not a lint fix.

Migration: per component, split defineOptions({ name, props }) into defineOptions({ name }) + defineProps({…}). 29 components already carry the invalid shape today (zaakafhandelapp 13, softwarecatalog 10, docudesk 6) — those break on any fresh install that resolves vue ≥ 3.5.41, independent of linting, so this one is the most urgent.

How to reproduce the withhold

npx eslint src --fix --rule '{"@nextcloud/l10n-enforce-ellipsis":"off","@nextcloud/l10n-non-breaking-space":"off","@nextcloud/no-deprecated-library-props":"off","vue/prefer-define-options":"off"}'

Burning debt down

npx eslint src --prune-suppressions after fixing a class removes its entries, so the counts in eslint-suppressions.json are the burn-down tracker.

[rubenvdlinde]

Correction to item 4 (vue/prefer-define-options)

I wrote that "29 components already carry the invalid shape today and break on any fresh install resolving vue ≥ 3.5.41, independent of linting", and called it the most urgent of the four.

That is wrong, and the error was mine. I measured the count while my own autofix run was still applied, before I reverted it. Verified on the merged development of all three apps:

zaakafhandelapp   defineOptions( occurrences: 0
softwarecatalog   defineOptions( occurrences: 0
docudesk          defineOptions( occurrences: 0

Not "zero with props" — zero defineOptions( calls at all. These apps use export default {…} in a plain <script> block, which is valid and unaffected by the vue 3.5.41 change. Nothing is broken on any branch today, and there is no fresh-install hazard.

What still stands

The rule's autofix is genuinely unsafe and must stay withheld. It is what creates the invalid shape: it moves export default {…} into defineOptions({…}) inside <script setup>, carrying props across, and @vue/compiler-sfc then rejects the result and the build fails. That was measured — it broke the build in softwarecatalog and docudesk during the migration, which is how it was found.

So this item is not urgent; it is a latent trap for whoever next runs eslint --fix without the withhold list. The recorded debt is the count of components the rule wants to convert:

app	files carrying vue/prefer-define-options debt
zaakafhandelapp	43
softwarecatalog	20
docudesk	15

Converting them is a real improvement, but it must be done deliberately — defineOptions({ name }) plus a separate defineProps({…}) — never by letting --fix do it.

🔑 The lesson I should have applied to my own number: a measurement taken while your own change is applied is a measurement of your change, not of the baseline.

[rubenvdlinde]

Two corrections and a measured burn-down table, from working through this today.

Correction 1 — item 4 is not urgent, and nothing is currently broken by it

The issue says of vue/prefer-define-options:

29 components already carry the invalid shape today (zaakafhandelapp 13, softwarecatalog 10, docudesk 6) — those break on any fresh install that resolves vue ≥ 3.5.41, independent of linting, so this one is the most urgent.

That is not true on development today. Measured on all three named apps, freshly checked out on development:

zaakafhandelapp   files containing `defineOptions` in src/**/*.vue : 0
softwarecatalog   files containing `defineOptions` in src/**/*.vue : 0
docudesk          files containing `defineOptions` in src/**/*.vue : 0

The invalid defineOptions({ name, props }) shape is what the autofix would create, not something the code carries. The rule is suppressed, so the autofix never ran, so nothing is broken. The two-script-block pattern that the autofix would mangle does exist (15 components in softwarecatalog alone), but that is the hazard, not damage already done.

Worth fixing in the issue text, because "most urgent" is currently steering the priority order wrongly — this is the least urgent of the four, not the most.

Correction 2 — item 3 is broader than the NcButton rename

@nextcloud/no-deprecated-library-props is described purely as NcButton type → variant. In openconnector, all three of its occurrences are something else entirely:

src/modals/Rule/EditRule.vue        1631, 1647  user-select      -> use NcSelectUsers
src/modals/v2/EndpointFormFields.vue 168        close-on-select  -> keep-open

And these are not lint debt — they are live UI bugs. Neither closeOnSelect nor userSelect is a declared prop on NcSelect in @nextcloud/vue 9; both fall through as inert attributes. NcSelect declares keepOpen and derives closeOnSelect: !this.keepOpen internally. So the multi-select has been closing on every pick, and two user pickers have been rendering as plain selects.

keepOpen being the inverse of closeOnSelect is a clean demonstration of why the withhold was right: a rename keeping the value gives :keepOpen="false" — still wrong, now with a green lint run. Fixed correctly in ConductionNL/openconnector#1267 (suppressions 3 → 2, tests 286 pass, build clean).

So the migration for item 3 is not one mechanical rename; each occurrence needs its own reading.

Measured burn-down, 2026-08-16

Counts read from each app's eslint-suppressions.json on development. ALL is every suppressed rule, not just these four.

app	defineOptions	libProps	ellipsis	nbsp	ALL
openregister	81	84	128	3	1254
procest	0	329	91	0	1044
opencatalogi	56	26	43	0	637
softwarecatalog	20	18	3	0	419
zaakafhandelapp	43	10	1	0	369
pipelinq	0	0	38	0	366
launchpad	0	80	0	2	289
hermiq	0	163	0	1	238
decidesk	0	0	6	4	215
docudesk	15	4	12	3	174
openconnector	0	3	2	0	173
openbuild	0	4	0	0	148
shillinq	0	1	19	1	146
doriath	0	0	5	0	131
scholiq	0	0	25	0	67
portaliq	0	0	0	0	24
TOTAL	215	722	373	14	5694

So the four withheld classes are 1,324 of 5,694 total suppressions. The concentration is worth noting when planning: libProps is 68% procest + hermiq + openregister + launchpad; ellipsis is 60% openregister + procest.

Suggested order, revised from the above: item 3 first (it contains real bugs, and openconnector shows each site needs individual reading), then item 1/2 together (same key-orphaning mechanism, must move source + locale files in one commit), then item 4 last (a semantic refactor with nothing currently broken behind it).

[rubenvdlinde]

Second data point on item 3 (@nextcloud/no-deprecated-library-props), and it strengthens the correction I posted earlier: this class is not one mechanical rename, and a sweep would actively break things.

Two apps, two live bugs, both polarity inversions

app	site	what it actually was
openconnector	EndpointFormFields.vue	:closeOnSelect="false" — not a prop on NcSelect. keepOpen is its inverse. The multi-select had been closing after every pick. Fixed in ConductionNL/openconnector#1267.
openbuild	4 dialogs	:canClose="…" — appears zero times in NcDialog. noClose is its inverse. Export/import/copilot/promote dialogs were all dismissible mid-work. Fixed in ConductionNL/openbuild#223.

In both cases the deprecated name was not a declared prop at all, so the binding fell through as an inert attribute and the guard silently did nothing. The rule was pointing at a real defect, not a style nit.

Why a sweep would be worse than the debt

noClose is the inverse of canClose, and three of openbuild's four were expressions:

:canClose="!submitting"                                  ->  :noClose="submitting"
:canClose="state !== 'planning' && state !== 'executing'" ->  :noClose="state === 'planning' || state === 'executing'"

The second is De Morgan, not a rename. An autofix that preserved the value would have inverted every guard — locking each dialog exactly when it should be closable — and produced a green lint run saying so. That is the "meaning, not layout" warning in this issue, demonstrated twice.

Suggested amendment to item 3

The issue describes this class as the NcButton type → variant rename. Measured across the two apps I have worked, the actual occurrences were:

user-select      -> use NcSelectUsers   (component swap, not a prop rename)
close-on-select  -> keep-open           (INVERTED)
can-close        -> no-close            (INVERTED)

None was the NcButton case. So the migration note should say: each occurrence needs reading; some are inversions and some are component swaps, and the remaining 714 sites cannot be estimated as one unit of work.

Running total on this class: 722 → 714 (openconnector 3→2, openbuild 4→0, shillinq 1 remaining). The two left in openconnector are user-select on NcSelect — the component-swap variety, which needs UI verification rather than an edit.

[rubenvdlinde]

Concrete measurement of item 2 (@nextcloud/l10n-non-breaking-space), and a blocker worth recording before anyone else tries it.

What one site actually costs

shillinq has exactly 1 occurrence, in src/views/settings/StandardsPolicyEditor.vue:

… (revenue, leases, inventory, …), business logic follows …
                              ^ 0x20, the rule wants 0xA0

Tracing that one string:

file	what it holds	what changing the source does
StandardsPolicyEditor.vue	the source string	—
l10n/en.json	key and value, identical (untranslated)	both must change, same line
l10n/nl.json	key + a real Dutch translation	key must change or the translation is orphaned

So the minimum correct change is four edits across three files, and the Dutch value carries its own 0x20 … that should move with it for consistency — five.

Two of the 37 locale files hold this key. The other 35 do not, which is the only reason this is a 5-edit change rather than a 37-edit one. That ratio will not hold for the openregister (128) or procest (91) occurrences of the sibling ellipsis rule.

The blocker

I could not make this change with text-editing tooling. U+00A0 does not survive the edit interface — it arrives as U+0020:

new_string I passed:  '…inventory, …)'
codepoints received:  0x79 0x2c 0x20 0x2026 0x29     ← 0x20, not 0xA0

Combined with the fleet rule against using sed/scripts to modify code files, this class is not agent-automatable by editing. And it is not reviewable by eye either — the diff shows two visually identical strings, which is the property this issue already warns about.

What would actually work

Something that operates on bytes and verifies afterwards, not a text edit:

1. a codemod that rewrites source + every locale key in one pass, keyed on the exact old string;
2. a post-check that reads the bytes back — [hex(ord(c)) for c in s] around each … — because "it looks right" is not evidence here;
3. npm run test:l10n on the same commit, which is the existing guard that catches an orphaned key.

Until that exists, my recommendation is to leave both l10n classes (item 1 ellipsis, 373 sites; item 2 nbsp, 14 sites) suppressed and not attempt them one file at a time. The suppression is doing its job: the debt is counted, the rule stays on, and any new occurrence still fails.

Nothing was changed — the attempt failed cleanly and the working tree is untouched.