@magfur-alam/prisma

The page builder's own, isolated Prisma schema and generated client — never shared with the host application's own database or Prisma schema. Multi-tenant from day one: every top-level model carries a tenantId (defaulting to "default" for single-tenant use).

Part of the Next.js Database-Backed Visual Page Builder monorepo — see the root README for the full architecture. Most apps won't import this package directly; @magfur-alam/next's createPageBuilder() wraps it.

Install

npm install @magfur-alam/prisma
npx page-builder generate   # or: npx page-builder init (also writes a .env placeholder)

Why generate first

This package ships its schema.prisma (so page-builder migrate/generate can find it) but not a pre-generated Prisma client — the generated client embeds a platform-specific query-engine binary, and baking one platform's binary into the npm package would silently break installs on every other platform. Run npx page-builder generate (or init, which also creates a .env placeholder) once after installing; it generates the client for your own platform, matching the exact prisma version this package depends on.

Usage

import { createPrismaClient, DEFAULT_TENANT_ID } from "@magfur-alam/prisma";

const prisma = createPrismaClient(process.env.PAGE_BUILDER_DATABASE_URL!);

@magfur-alam/next's CLI also uses resolvePrismaBinPath(), exported from the separate @magfur-alam/prisma/cli-support subpath (deliberately not the main entry above — see below) — it resolves the on-disk path to this package's own locally-installed prisma CLI, so page-builder migrate/ generate always run the exact version this package depends on directly, never npx prisma (which falls through to npm's registry if prisma isn't found locally — a real bug this project hit once, see PLAN.md's Phase 8 notes).

Why a separate subpath, not just another export from the top? The main entry (import ... from "@magfur-alam/prisma") eagerly re-exports the generated Prisma client, which doesn't exist until generate has run. resolvePrismaBinPath() is what generate itself needs to run in the first place — exporting it from the same barrel would mean requiring it at all breaks on every fresh install, before generate ever gets the chance to fix that. A second real bug this project hit once, found the same way as the first: by actually installing a packed tarball into a fresh directory and running the CLI, not just trusting the code.