@cat-factory/app 0.131.0 → 0.132.0

package/app/modular/registry.spec.ts

@@ -0,0 +1,31 @@
+import { defineModule } from '@modular-vue/core'
+import { afterEach, describe, expect, it } from 'vitest'
+import { __resetConsumerModulesForTest, createAppRegistry, registerAppModule } from './registry'
+
+describe('app modular registry', () => {
+  afterEach(() => {
+    __resetConsumerModulesForTest()
+  })
+
+  it('registers the first-party core module', () => {
+    const manifest = createAppRegistry().resolveManifest()
+    expect(manifest.modules.map((m) => m.id)).toContain('cat-factory:core')
+  })
+
+  it('includes consumer modules contributed via registerAppModule', () => {
+    registerAppModule(defineModule({ id: 'consumer:example', version: '1.0.0' }))
+
+    const ids = createAppRegistry()
+      .resolveManifest()
+      .modules.map((m) => m.id)
+
+    expect(ids).toContain('cat-factory:core')
+    expect(ids).toContain('consumer:example')
+  })
+
+  it('rejects a module whose id collides with an already-registered one', () => {
+    registerAppModule(defineModule({ id: 'cat-factory:core', version: '2.0.0' }))
+
+    expect(() => createAppRegistry().resolveManifest()).toThrow(/duplicate/i)
+  })
+})

package/app/modular/registry.ts

@@ -0,0 +1,75 @@
+import { defineModule } from '@modular-vue/core'
+import type { AnyModuleDescriptor } from '@modular-vue/core'
+import { createRegistry } from '@modular-vue/runtime'
+import type { ModuleRegistry } from '@modular-vue/runtime'
+
+/**
+ * modular-vue registry for the `@cat-factory/app` layer (slice 0 of the
+ * modular-vue adoption — docs/initiatives/modular-vue-adoption.md).
+ *
+ * This is the frontend analogue of the backend's public registries
+ * (`registerAgentKind`, `registerGate`): a single registry into which the layer
+ * registers its own first-party feature modules AND a consumer deployment
+ * contributes its own, all through the same seam. The registry is resolved and
+ * installed by `app/plugins/modular.client.ts`.
+ *
+ * Slice 0 wires the plumbing behind ZERO behaviour change: the one first-party
+ * module carries no navigation / slots / component, so nothing new renders.
+ * Later slices convert real areas (navigation, result views, wizards, inspector
+ * panels) into modules registered here.
+ */
+
+/**
+ * First-party modules the layer always registers. Kept tiny on purpose for
+ * slice 0 — a single descriptor with no contributions, present only to prove the
+ * registration pipeline end to end and give the seam a stable anchor. Real
+ * feature modules land here as later slices convert each area.
+ */
+const FIRST_PARTY_MODULES: readonly AnyModuleDescriptor[] = [
+  defineModule({ id: 'cat-factory:core', version: '1.0.0' }),
+]
+
+/**
+ * Consumer-contributed modules, collected before the layer resolves its
+ * registry. A deployment extending `@cat-factory/app` calls
+ * {@link registerAppModule} from its own Nuxt plugin (which runs before the
+ * layer's install plugin — see the ordering note in
+ * `app/plugins/modular.client.ts`). Module descriptors carry Vue components, so
+ * they can't travel through serializable Nuxt config; this in-process seam is
+ * how the layer stays unforked while a consumer contributes real components.
+ */
+const consumerModules: AnyModuleDescriptor[] = []
+
+/**
+ * Contribute a module to the app registry from a consumer deployment (or a
+ * first-party plugin). Call this at plugin-setup time, before the layer's
+ * install plugin resolves the registry. Registering the same id twice makes
+ * `resolve()` throw at build time (duplicate-id validation), which is the
+ * intended guard.
+ */
+export function registerAppModule(module: AnyModuleDescriptor): void {
+  consumerModules.push(module)
+}
+
+/**
+ * Test-only: drop every consumer-registered module so a spec can exercise
+ * {@link registerAppModule} without leaking state into the next test. Not part
+ * of the runtime seam.
+ */
+export function __resetConsumerModulesForTest(): void {
+  consumerModules.length = 0
+}
+
+/**
+ * Build a fresh registry with the first-party modules plus everything a consumer
+ * contributed via {@link registerAppModule}. A new registry per call because
+ * `resolve()` / `resolveManifest()` are single-commit; the install plugin calls
+ * this exactly once at client startup (`ssr: false`, so a singleton app).
+ */
+export function createAppRegistry(): ModuleRegistry<Record<string, unknown>> {
+  const registry = createRegistry<Record<string, unknown>>({})
+  for (const mod of [...FIRST_PARTY_MODULES, ...consumerModules]) {
+    registry.register(mod)
+  }
+  return registry
+}

package/app/plugins/modular.client.ts

@@ -0,0 +1,32 @@
+import { installModularApp } from '@modular-vue/nuxt/runtime'
+import { createAppRegistry } from '~/modular/registry'
+
+/**
+ * Wire the modular-vue registry into the Nuxt app (slice 0 of the modular-vue
+ * adoption — docs/initiatives/modular-vue-adoption.md).
+ *
+ * `enforce: 'post'` is load-bearing for the consumer-contribution seam. Nuxt
+ * loads layer plugins before the consuming app's plugins within the same enforce
+ * bucket, so a consumer that calls `registerAppModule(...)` from a normal plugin
+ * would otherwise run AFTER this one and miss the resolve. Putting this plugin in
+ * the `post` bucket flips the order: the consumer's default-bucket registration
+ * runs first, then this resolves the registry with everything registered. A
+ * consumer therefore contributes from a default (or `pre`) plugin — documented
+ * in the framework-mode-nuxt guide upstream.
+ *
+ * `ssr: false`, so this runs once on the client and a singleton registry is
+ * fine. `installModularApp` is the router-owning path: it grafts each module's
+ * routes onto Nuxt's router (none yet — slice 0 modules are non-routed) and
+ * installs the modular contexts (shared deps, navigation, slots) app-wide. The
+ * resolved manifest is exposed as `$modular` for later slices; nothing reads it
+ * yet, which is what keeps this behaviour-neutral.
+ */
+export default defineNuxtPlugin({
+  name: 'cat-factory:modular',
+  enforce: 'post',
+  setup(nuxtApp) {
+    const registry = createAppRegistry()
+    const manifest = installModularApp({ vueApp: nuxtApp.vueApp, $router: useRouter() }, registry)
+    return { provide: { modular: manifest } }
+  },
+})

package/app/utils/modular.ts

@@ -0,0 +1,11 @@
+/**
+ * Auto-imported seam for the modular-vue registry. Re-exported from `app/utils/`
+ * (which Nuxt auto-imports across the whole `extends` chain) so a consumer
+ * deployment can contribute modules with a bare `registerAppModule(...)` call
+ * from its own plugin — no deep import into the layer's internals, the same
+ * ergonomics as the layer's auto-imported stores and composables.
+ *
+ * See `app/modular/registry.ts` for the seam itself and
+ * docs/initiatives/modular-vue-adoption.md for the adoption plan.
+ */
+export { registerAppModule } from '~/modular/registry'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cat-factory/app",
-  "version": "0.131.0",
+  "version": "0.132.0",
   "description": "Reusable Nuxt layer for the Agent Architecture Board SPA (components, stores, composables, pages). Consume it from a thin deployment app via `extends: ['@cat-factory/app']` and point it at your backend with NUXT_PUBLIC_API_BASE. See deploy/frontend for an example.",
   "repository": {
     "type": "git",
@@ -18,6 +18,11 @@
     "access": "public"
   },
   "dependencies": {
+    "@modular-frontend/core": "^0.1.0",
+    "@modular-vue/core": "^1.0.1",
+    "@modular-vue/nuxt": "^0.1.1",
+    "@modular-vue/runtime": "^1.0.1",
+    "@modular-vue/vue": "^1.0.0",
     "@nuxt/ui": "^4.9.0",
     "@nuxtjs/i18n": "^10.4.1",
     "@pinia/nuxt": "^0.11.3",
@@ -32,7 +37,7 @@
     "pinia": "^3.0.4",
     "pinia-plugin-persistedstate": "^4.7.1",
     "valibot": "^1.4.2",
-    "vue": "3.5.39",
+    "vue": "3.5.40",
     "wretch": "^3.0.9",
     "@cat-factory/contracts": "0.147.1"
   },