Add JavaScript frontend extensibility

[malberts]

Fixes #686

Implements Option 1 from the design discussion on #686 — mw.hook('neowiki.registration') with plain-object registrations, MW-native ResourceLoader modules, and plain .vue SFCs for extensions. No bundler or TypeScript required on the extension side.

Summary

Lets external MediaWiki extensions register custom frontend property types at runtime, without touching NeoWiki source or rebuilding its bundle. This PR adds the mechanism only; no consumer is in-tree. Companion PRs exercise it:

• [REFERENCE] Move DateTime frontend from NeoWiki core to RedHerb #777 datetime-example — reference PR demonstrating migration of a core property type (DateTime) into an extension. Not intended to merge; exists as a live worked example.
• Upcoming Color PR — first permanent consumer, Color as a RedHerb test property type.

What this PR ships

• JS hook mw.hook('neowiki.registration') — subscribers receive a FrontendRegistrar and call registrar.registerPropertyType({...}) with a plain-object PropertyTypeRegistration. An internal PropertyTypeAdapter wraps each registration as a BasePropertyType; the registrar inserts it into NeoWiki's component and property-type registries.
• PHP hook NeoWikiGetFrontendModules( array &$modules, OutputPage $out, Skin $skin ) — extensions append their ResourceLoader module names; NeoWiki adds them alongside ext.neowiki on any page that loads it. Consumed in onBeforePageDisplay plus the Special:Schemas and Special:Layouts entry points.
• Public-API barrel resources/ext.neowiki/src/public-api.ts — re-exports every TS module and Vue component under resources/ext.neowiki/src/ (83 TS files, 52 Vue files, ~146 runtime names). 0.x / alpha stability contract: anything may change without migration guidance, narrowed before production stabilisation.
• Memoized registries — NeoWikiExtension.getTypeSpecificComponentRegistry() and Neo.getPropertyTypeRegistry() return the same instance per call, so the registry the hook populates is the same one NeoWikiServices provides to Vue.
• Mount deferral — each initialize* function in neowiki.ts wraps its body in queueMicrotask and fires the registration hook before deserialization and mount, giving extension init.js files a chance to subscribe first.

Jeroen's three usage modes (from this comment)

The mechanism itself supports all three. The consumer PRs exercise them end-to-end:

Mode	Mechanism support in this PR	Example consumer
Register a property type	✓ mw.hook('neowiki.registration') + FrontendRegistrar	datetime-example (#777); upcoming Color PR
Import and use a NeoWiki Vue component	✓ Broad public-API barrel re-exports every Vue component	datetime-example uses NeoNestedField; Color PR plans NeoMultiTextInput, EditSummary
Call a NeoWiki service from JS	✓ Broad barrel re-exports every TS module	datetime-example calls NeoWikiServices.getPropertyTypeRegistry().getType(...).validate(...); Color PR plans stores + composables + a repository

Commits

1. Introduce public-API barrel and memoize registries — preparatory; no user-visible behaviour change.
2. Add neowiki.registration JS hook and NeoWikiGetFrontendModules PHP hook — full mechanism. Integration-test (resources/ext.neowiki/tests/integration/HookRegistration.spec.ts) proves end-to-end via a fake registration.
3. Expose broad public API surface — turns the narrow barrel into a wildcard re-export of every TS module and Vue component under src/.

Test plan

• make tsci green — 771 Vitest tests across 78 files, 266 bundler modules transformed
• make phpunit full suite — pre-existing unrelated failure in Neo4jConstraintUpdaterTest::testDefaultConstraintsAreCreated (version drift UNIQUENESS vs NODE_PROPERTY_UNIQUENESS) reproduces on master
• make cs phpcs + phpstan clean
• Integration test HookRegistration.spec.ts exercises .fire() before subscribe + .add() after .fire() (mw.hook replay semantics) — both code paths green
• Public-API barrel coverage audit: 83 TS files on disk ↔ 83 TS exports; 52 Vue files on disk ↔ 52 Vue exports — exact match

Manual browser check

Because this PR has no in-tree consumer, end-to-end UI verification lives in the consumer PRs. From the repo root, make import-demo-data (if needed) and docker compose restart mediawiki. Log in as AdminName / AdminPassword.

Mechanism-only checks

• http://localhost:8484/index.php/Main_Page loads without console errors.
• http://localhost:8484/index.php/Special:Schemas, Special:Layouts, and any existing Schema: or Layout: page render without console errors.
• curl 'http://localhost:8484/load.php?modules=ext.neowiki&only=scripts&lang=en&debug=true' returns 200 and the response includes the 146 named exports on module.exports (inspect the tail of the bundle).
• From a browser console on any NeoWiki page:

  const nw = mw.loader.require( 'ext.neowiki' );
  Object.keys( nw ).length; // ≥ 146
  typeof nw.NeoWikiServices; // 'object'
  typeof nw.FrontendRegistrar; // 'function'

• Pre-existing property types (Text / Number / URL / Select / Relation / DateTime) still work end-to-end — no regressions from the barrel refactor, registry memoization, or queueMicrotask deferral.

Full end-to-end via a consumer

For end-to-end verification of the registration flow itself, either check out datetime-example (PR #777) or the upcoming Color PR and follow its test plan. The integration test in this PR covers the same flow at the unit level.

Follow-ups

• Curation pass before production — audit which of the 146 barrel exports are actually useful to consumers vs. internal-only; narrow the surface and document the stable contract.
• Name-collision regression guard — export * errors at build when two modules grow an identically-named export. Fine for now; worth a script/check if the source tree grows a lot.
• Graceful degradation when a type-owning extension is disabled — observed in datetime-example: disabling the extension leaves stored data using that type unrenderable and the NeoWiki UI container empty. Architecturally expected for extension-owned types, but worth a "unknown property type" placeholder component rather than aborting the whole view.

[malberts]

So far Claude has done browser tests, and I have also done manual tests for a full end-to-end flow: Create Schema -> Create Subject -> View Subject -> Edit Schema -> Edit Subject -> View Subject.

This does not consider the recent comments in #686 (comment).

[JeroenDeDauw]

Result of extensive back and forth with @JeroenDeDauw reviewing this PR against a parallel architectural options analysis.
Context: the NeoWiki codebase, the discussion on #686, and the trade-off space around the ext.neowiki public API surface.
_{Written by Claude Code, Opus 4.7}

Strongly aligned with #686's design direction. Structural choices match; a few things worth calling out.

Aligned

• Public-API barrel at resources/ext.neowiki/src/public-api.ts
• mw.hook('neowiki.registration') + FrontendRegistrar + plain-object PropertyTypeRegistration + internal PropertyTypeAdapter
• Memoized registries — the fresh-per-getter pattern was a concrete blocker, this fixes it
• Hook-fire timing resolved via queueMicrotask wrapping in neowiki.ts's initialize functions
• DateTime moved from core to RedHerb as end-to-end proof
• All three usage modes exercised by RedHerb's DateTime (register, consume component via NeoNestedField, call service via PropertyTypeRegistry)

Points worth flagging

1. Three commits in one PR rather than three mergeables. Combining them is a reasonable judgment call — validation loop stays intact. Does mean the standalone benefit of the barrel commit (consumption unblocked independently of the hook) is deferred until the whole thing lands.

2. Public API starts narrow vs broad. The PR describes the barrel as "starts narrow… and grows organically as real usage demands". Alternative position: broad-and-provisional during alpha — expose a superset, narrow before stability. Arguable both ways. Narrow-and-grow is conservative and nothing accidentally becomes public; it does mean downstream consumers will hit "not exported" friction more often during the alpha build-out. Worth an explicit call, either way.

3. NeoWikiGetFrontendModules PHP hook is a good addition. Not in the original sketch but solves the real problem of how does ext.redherb actually get loaded on a NeoWiki page. Cleanly separates discovery from registration.

Open items worth checking in the diff

• Pinia instance sharing. Doesn't matter for DateTime since it doesn't touch stores, but the moment an extension component binds to useSubjectStore or similar, a mismatched Pinia instance would silently break reactivity. Worth verifying a single instance is shared across NeoWiki's mounts and reachable by extension components.
• Whether PropertyTypeRegistration is derived from BasePropertyType via TS utility types (issue Add frontend extension mechanism for property types #686 mechanism 3) or written by hand. Former self-syncs with class changes; latter drifts silently.

Observations worth preserving

• The "silent UI failure when a type-owning extension is disabled" follow-up is architecturally important. Disabled extension + stored statements of its type = blank NeoWiki UI. Placeholder rows (or similar graceful degradation) deserve to happen before production. Also a reason core types belong in core.
• Flagging that DateTime should return to core rather than live permanently in RedHerb is correct. Temporary forcing function = fine; permanent home = wrong.

Overall: tracks the agreed direction and makes two sensible judgment calls on top. The narrow-vs-broad API surface is the one decision I'd want confirmed explicitly before it solidifies.

[malberts]

Three commits in one PR rather than three mergeables.

Seems better to have a fully working initial example in one PR.

Public API starts narrow vs broad.

#760

That adds everything (for now).

Pinia instance sharing

Likely TODO in a follow-up. Maybe as part of the same non-DateTime example.

The "silent UI failure when a type-owning extension is disabled" follow-up is architecturally important.

This should be split off into a new issue. While more likely to happen with extensions, it can still theoretically happen in core if we removed a type.

---

I need to do some final reviews on this PR, and see if I can come up with an alternative to DateTime so we do not have to jump around between core and RedHerb. Otherwise, if we keep the revertable commit, we can just undo this a little bit later once we have a different example to keep in RedHerb.

[malberts]

I decided to split out the DateTime implementation into #777. It seems like we would just be moving that up and down for the sake of an example. I'm keeping that PR, but will follow-up with a Color example instead, which can stay in RedHerb and not require us to mess around with a property type that is a requirement. After the Color PR we should move all the DateTime code in RedHerb into core instead.