@prisma-next/extension-paradedb 0.11.0-dev.63 → 0.11.0-dev.64

package/README.md

@@ -75,8 +75,8 @@ ParadeDB BM25 indexes require a `key_field` — a unique column that identifies
 
 The extension's contract + baseline migration are emitted on-disk inside this package using the same pipeline application authors use:
 
-- `pnpm build:contract-space` — runs `prisma-next contract emit` to produce `src/contract.{json,d.ts}` from the PSL source at `src/contract.prisma`.
-- `pnpm exec prisma-next migration plan --name <slug>` (run from this package directory) — scaffolds a new migration directory under `migrations/<dirName>/` for schema changes. **Not chained into `pnpm build`**: `migration plan` is non-idempotent (each invocation generates a new timestamped directory), so it runs manually when the contract source changes. Note: paradedb's contract declares no tables or models, so the planner currently refuses to scaffold the baseline migration (this is **Path B** authoring per [ADR 212](../../../docs/architecture%20docs/adrs/ADR%20212%20-%20Contract%20spaces.md#contract-space-package-layout)). That directory was hand-authored once (Migration subclass + seed `migration.json` preserving the full `toContract`) and `pnpm tsx migrations/<dirName>/migration.ts` re-emits `ops.json` + `migration.json` deterministically. Future migrations that add tables or models can use `migration plan` directly (Path A).
+- `pnpm build:contract-space` — runs `prisma-next contract emit` to produce `src/contract.{json,d.ts}` from `emptyContract({ output: 'src/contract.json', target })` in `prisma-next.config.ts` (migrations-only space: no `contract.prisma` source file).
+- `pnpm exec prisma-next migration plan --name <slug>` (run from this package directory) — scaffolds a new migration directory under `migrations/<dirName>/` for schema changes. **Not chained into `pnpm build`**: `migration plan` is non-idempotent (each invocation generates a new timestamped directory), so it runs manually when the contract changes. Note: paradedb's contract declares no tables or models, so the planner currently refuses to scaffold the baseline migration (this is **Path B** authoring per [ADR 212](../../../docs/architecture%20docs/adrs/ADR%20212%20-%20Contract%20spaces.md#contract-space-package-layout)). That directory was hand-authored once (Migration subclass + seed `migration.json` preserving the full `toContract`) and `pnpm tsx migrations/<dirName>/migration.ts` re-emits `ops.json` + `migration.json` deterministically. Future migrations that add tables or models can use `migration plan` directly (Path A).
 - `pnpm tsx migrations/<dirName>/migration.ts` (run from this package directory) — re-emits `ops.json` + `migration.json` from the hand-edited subclass. Use `tsx`, not bare `node`, because the Migration subclass imports relative TypeScript siblings which Node's native loader can't resolve without a TS-aware loader.
 - `migrations/refs/head.json` is hand-pinned with the latest migration's `to` hash + `providedInvariants`.
 

package/package.json

@@ -1,30 +1,30 @@
 {
   "name": "@prisma-next/extension-paradedb",
-  "version": "0.11.0-dev.63",
+  "version": "0.11.0-dev.64",
   "license": "Apache-2.0",
   "type": "module",
   "sideEffects": false,
   "dependencies": {
-    "@prisma-next/contract": "0.11.0-dev.63",
-    "@prisma-next/contract-authoring": "0.11.0-dev.63",
-    "@prisma-next/family-sql": "0.11.0-dev.63",
-    "@prisma-next/framework-components": "0.11.0-dev.63",
-    "@prisma-next/migration-tools": "0.11.0-dev.63",
-    "@prisma-next/sql-contract": "0.11.0-dev.63",
-    "@prisma-next/sql-operations": "0.11.0-dev.63",
-    "@prisma-next/sql-relational-core": "0.11.0-dev.63",
-    "@prisma-next/sql-runtime": "0.11.0-dev.63",
+    "@prisma-next/contract": "0.11.0-dev.64",
+    "@prisma-next/contract-authoring": "0.11.0-dev.64",
+    "@prisma-next/family-sql": "0.11.0-dev.64",
+    "@prisma-next/framework-components": "0.11.0-dev.64",
+    "@prisma-next/migration-tools": "0.11.0-dev.64",
+    "@prisma-next/sql-contract": "0.11.0-dev.64",
+    "@prisma-next/sql-operations": "0.11.0-dev.64",
+    "@prisma-next/sql-relational-core": "0.11.0-dev.64",
+    "@prisma-next/sql-runtime": "0.11.0-dev.64",
     "arktype": "^2.2.0"
   },
   "devDependencies": {
-    "@prisma-next/adapter-postgres": "0.11.0-dev.63",
-    "@prisma-next/cli": "0.11.0-dev.63",
-    "@prisma-next/operations": "0.11.0-dev.63",
-    "@prisma-next/sql-contract-ts": "0.11.0-dev.63",
-    "@prisma-next/target-postgres": "0.11.0-dev.63",
-    "@prisma-next/test-utils": "0.11.0-dev.63",
-    "@prisma-next/tsconfig": "0.11.0-dev.63",
-    "@prisma-next/tsdown": "0.11.0-dev.63",
+    "@prisma-next/adapter-postgres": "0.11.0-dev.64",
+    "@prisma-next/cli": "0.11.0-dev.64",
+    "@prisma-next/operations": "0.11.0-dev.64",
+    "@prisma-next/sql-contract-ts": "0.11.0-dev.64",
+    "@prisma-next/target-postgres": "0.11.0-dev.64",
+    "@prisma-next/test-utils": "0.11.0-dev.64",
+    "@prisma-next/tsconfig": "0.11.0-dev.64",
+    "@prisma-next/tsdown": "0.11.0-dev.64",
     "tsdown": "0.22.0",
     "typescript": "5.9.3",
     "vitest": "4.1.6"

package/src/contract.prisma

@@ -1,22 +0,0 @@
-// PSL contract source for the `extension-paradedb` package.
-//
-// Authored against the contract-space package layout convention. The same
-// emit pipeline application authors use is applied here:
-//
-//   `prisma-next contract emit` → `<package>/src/contract.{json,d.ts}`
-//   `prisma-next migration plan` → `<package>/migrations/<dirName>/`
-//
-// The descriptor at `src/exports/control.ts` then wires the emitted JSON
-// artefacts via JSON-import declarations.
-//
-// ## IR coverage
-//
-// paradedb ships **no tables** and **no native types** of its own. Its
-// baseline migration installs the `pg_search` Postgres extension; all
-// BM25 index configuration is carried by the user contract's own models
-// (via the `'bm25'` index-type entry registered in `src/types/index-types.ts`).
-// The contract IR is therefore intentionally empty — the space is still
-// required so the migration runner can track the `pg_search` installation
-// invariant independently of any user models.
-//
-// @see docs/architecture docs/adrs/ADR 212 - Contract spaces.md