@zenbujs/core 0.0.8 → 0.0.12

package/dist/registry-CMp8FYgS.d.mts

@@ -1,47 +0,0 @@
-//#region src/registry.d.ts
-/**
- * The registry seam.
- *
- * `ZenbuRegister` is the empty interface that downstream apps (and
- * core's own `pnpm link:types` output) augment via:
- *
- *     declare module "@zenbujs/core/registry" {
- *       interface ZenbuRegister {
- *         db: DbRoot
- *         rpc: ServiceRouter
- *         events: PluginEvents
- *       }
- *     }
- *
- * Server services (`DbService.client`, `RpcService.emit`) and renderer
- * hooks (`useDb`, `useRpc`, `useEvents`) all read their types from
- * `ZenbuRegister` via the `Resolved*` aliases below, so each TS program
- * sees its own merged surface without generics at the call site.
- *
- * Concrete types live elsewhere:
- *   - core's published surface: `@zenbujs/core/registry-generated`
- *     (regenerated by `pnpm link:types`, shipped via tsdown -> dist/)
- *   - downstream's user-side surface: `<app>/types/services.ts` etc.
- *     (regenerated by `zen link`)
- *
- * registry.ts itself stays minimal on purpose: only the augmentation
- * target + plug-and-play fallbacks. Anything more would need to be
- * hand-maintained, and we want the link generator to be the single
- * source of truth.
- *
- * Mirrors the pattern TanStack Router uses for `Register`.
- */
-interface ZenbuRegister {}
-type ResolvedDbRoot = ZenbuRegister extends {
-  db: infer T;
-} ? T : {
-  plugin: {};
-};
-type ResolvedServiceRouter = ZenbuRegister extends {
-  rpc: infer T;
-} ? T : {};
-type ResolvedEvents = ZenbuRegister extends {
-  events: infer T;
-} ? T : {};
-//#endregion
-export { ZenbuRegister as i, ResolvedEvents as n, ResolvedServiceRouter as r, ResolvedDbRoot as t };