Vue 2.7 + Pinia frontend scaffold + v2 manifest (Phase 2 deferred)

[rubenvdlinde]

Summary

Phase 2 of the v2 manifest fleet rollout (hydra ADR-036) intended to give larpingapp a Vue frontend with a v2 manifest from day one. The scaffold work got ~80% done but the build doesn't run cleanly yet, so this work is deferred to a focused follow-up session.

What's complete (in /tmp/worktrees/larpingapp-vue-scaffold)

• package.json with @conduction/nextcloud-vue@^1.0.0-beta.58 + Pinia + nc-vue Nc* re-exports
• webpack.config.js (copied from nextcloud-app-template scaffold-v2 reference)
• src/main.js — bootstrap with manifest + registry + customComponents
• src/App.vue — CnAppRoot wrapper with objectSidebarState provide, registry prop, customComponents prop
• src/manifest.json — 21 pages (9 index, 9 detail, 1 dashboard, 1 settings, 1 custom), $schema pointing at v2, codemod-converted to v2 shape
• src/registry.js — 5-kind component registry with the FeaturesRoadmap page entry
• src/customComponents.js — v1 backward-compat (just FeaturesRoadmap)
• src/views/ — placeholder views generated by the scaffolding subagent
• 13 commits ahead of origin/development (uncommitted, in the worktree)

What's NOT complete

1. npm run build fails — missing babel-loader (added to package.json but build still doesn't find it), @nextcloud/axios webpack-alias issues per ADR-024's known prerequisites
2. No composer.json integration — larpingapp is currently a server-side PHP app with PHP templates; the Vue mount strategy (Step 6 of the original brief — replace templates/main.php vs add a new route) wasn't decided
3. PHP controllers ↔ Vue pages not wired — manifest references entities like Characters, Players, Events but the v2 pages use register: 'larpingapp', schema: '<entity>' assuming OpenRegister storage. larpingapp currently uses its own PHP controllers, not OR. Either:
   • Migrate larpingapp's data to OpenRegister (preferred long-term, matches mydash #206 pattern)
   • OR keep all pages as type: "custom" with bespoke Vue views that call existing PHP endpoints
4. No lint/test passes — build needs to succeed first

Suggested next-session approach

1. Resume in the existing worktree at /tmp/worktrees/larpingapp-vue-scaffold
2. Fix the build:
   • Verify babel-loader, @babel/core, @babel/preset-env in devDeps
   • Add the @nextcloud/axios$ webpack alias (per ADR-024 build-time prerequisites)
   • Add node-polyfill-webpack-plugin if Buffer/process polyfills are needed for axios
3. Decide PHP integration:
   • Read existing templates/main.php and lib/Controller/* to understand the current entry
   • Either replace templates/main.php to mount Vue, or add a new route /apps/larpingapp/v2 that does
4. Decide data path:
   • Adopt OpenRegister (file in lib/Settings/larpingapp_register.json like mydash #206)
   • OR keep all pages type: "custom" and adapt to the existing PHP API
5. npm run build → green
6. validateManifestV2(manifest) → { valid: true }
7. Test in browser
8. Open PR

References

• hydra ADR-036 — v2 manifest design
• nextcloud-app-template #44 — canonical v2 scaffold template
• procest #512 — codemod migration reference
• mydash #206 — runtime-manifest + OR storage reference
• ADR-024 build prerequisites (@nextcloud/axios alias, etc.)

Why deferred

The 5 other Phase 2 apps (shillinq, pipelinq, openbuilt, softwarecatalog, zaakafhandelapp) were straightforward codemod migrations and merged in Phase 2 today. larpingapp's scope is bigger: it needs a whole new Vue frontend, not just a manifest conversion. Doing it well requires focused effort on the PHP↔Vue integration boundary, which a tired session couldn't deliver cleanly.

ADR-024 originally marked larpingapp "N/A" (server-side PHP, no Vue Router, no SPA shell). This issue overrides that classification — Vue scaffold is desired — but it's a substantial multi-hour project deserving its own session.