basalt / prisma/src / PrismaSyncCommandOptions

Interface: PrismaSyncCommandOptions

Defined in: prisma/src/sync-command.ts:18

Properties

domains?

> optional domains?: string[]

Defined in: prisma/src/sync-command.ts:22

Restrict discovery to these domains (else: every installed *-prisma).

---

schemaPath?

> optional schemaPath?: string

Defined in: prisma/src/sync-command.ts:20

App schema path. Default: prisma/schema.prisma. Override with --schema.

---

targets?

> optional targets?: Record<string, PrismaSyncTarget>

Defined in: prisma/src/sync-command.ts:48

Two or more schemas, each with the domains that belong in it.

DOMAINS mixes domains that live in every tenant's schema (auth, permissions, audit, activity, teams, notifications) with domains that live only in the central one (tenancy, subscriptions). Nothing in a package says which is which — placement is a decision of the application, and until now the command had no way to be told.

So prisma:sync --yes, the obvious invocation, wrote Tenant, Subscription and Payment into the schema of every tenant. Those tables must never hold a row, and having them there is a place for one tenant's data to land unnoticed.

prismaSyncCommand({
  targets: {
    central: { schemaPath: 'prisma/schema.prisma', domains: ['tenancy', 'subscriptions'] },
    tenant: { schemaPath: 'prisma/tenants/schema.prisma', domains: ['auth', 'permissions'] },
  },
})

Without it the command behaves exactly as before — one schema, one list.