Add tests for Vue components in RedHerb

[JeroenDeDauw]

So we can catch when they break

[JeroenDeDauw]

Investigation triggered by code review of #790 / #798 with @JeroenDeDauw.
Context: the NeoWiki codebase, RedHerb's Vue components, and the existing vitest setup under resources/ext.neowiki/.
_{Written by Claude Code, Opus 4.7 (1M context)}

Scope: 6 Vue components and 1 helper

All currently untested on the JS side:

• tests/RedHerb/resources/ColorAttributesEditor.vue
• tests/RedHerb/resources/ColorDisplay.vue
• tests/RedHerb/resources/ColorInput.vue
• tests/RedHerb/resources/createChild/CreateChildDialog.vue
• tests/RedHerb/resources/editMainSubject/EditMainSubjectDialog.vue
• tests/RedHerb/resources/subjectFinder/SubjectFinderPanel.vue
• tests/RedHerb/resources/hexRegex.js

PHP side already has coverage (ColorPropertyTest, DateTimePropertyTest, hook tests, special page test). The gap is JS/Vue only.

Why no tests exist today

Three frictions:

1. Vitest project root is resources/ext.neowiki/. RedHerb lives outside that root, so default vitest run doesn't discover specs there.
2. RedHerb's Vue components use the Options API in CommonJS form — var vue = require( 'vue' ); module.exports = { ... }. That is how MediaWiki ResourceLoader serves them. The vue plugin handles this fine; it is just shaped differently from the rest of the suite.
3. Components consume require( 'ext.neowiki' ) — the public-API barrel — through ResourceLoader's runtime resolution. In tests this needs an alias.

Two approaches for the harness

Option A: vitest workspace. Add vitest.workspace.ts listing two projects: the existing one rooted at resources/ext.neowiki/, plus a second rooted at the extension root with include pattern tests/RedHerb/**/*.spec.ts. Each project owns its own aliases and mocks. Cleanest separation; mirrors that RedHerb is conceptually a separate extension.

Option B: extend the existing vitest project. Add tests/RedHerb/** to the include pattern and add aliases/mocks to the existing config. Smaller diff but blurs the extension boundary.

I would go with A.

Module aliases / mocks needed regardless of approach

• ext.neowiki → src/public-api.ts (so require( 'ext.neowiki' ) resolves to the real barrel)
• ./codex.js (RedHerb-local RL bridge file) → @wikimedia/codex (or a stub re-export)
• mw globals (mw.message, mw.notify, mw.log, mw.config, mw.storage) — setupMwMock already exists in resources/ext.neowiki/tests/VueTestHelpers.ts; reuse rather than duplicate
• ./constants.js (per-dialog injection keys like DIALOG_OPEN_KEY, DIALOG_STATE_KEY) — provide via Vue's provide in test setup

Smoke-test scope per component

Aim for catching contract breakage, not deep behavior coverage. Per dialog:

1. Mounts without throwing given realistic props/provides. Catches "method I am calling on the public API does not exist anymore." This alone would have caught the schemaProperties → schema rename in Move schema-driven statement merging into Schema #798.
2. Passes expected props to nw.SubjectEditor (or whichever NeoWiki component it composes). Stub nw.SubjectEditor; assert on received props.
3. One representative interaction — open, save, error path. Optional second pass once the harness is proven.

Color components are simpler — plain inputs/displays. Each needs mount + a model-value round-trip test.

hexRegex.js is pure logic, no harness needed beyond a plain import in a unit spec.

Recent-history signal

The 4 commits immediately before #798 were all on RedHerb's Color components (Tighten Color hex-validation naming, Drop redundant dirty marker from ColorAttributesEditor, Build ColorInput on nw.useStringValueInput, Reject invalid default values in ColorProperty constructor). Active development with no automated coverage; smoke tests would have given each of those a regression net.

Suggested order

1. Set up the workspace + aliases + module-mock helpers (one-time harness PR, no behavior tests yet).
2. Smoke tests for CreateChildDialog and EditMainSubjectDialog — the dialogs that exercise nw.SubjectEditor, nw.useSchemaStore, nw.useSubjectStore. Most likely to break on public-API changes.
3. Smoke tests for the Color components and SubjectFinderPanel.
4. hexRegex.js unit tests (trivial).

Splitting step 1 from steps 2-4 lets the harness land cleanly so reviewers do not have to evaluate "is this test useful" alongside "is this harness right."