@prisma/composer 0.14.0 → 0.15.0-dev.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prisma/composer",
-  "version": "0.14.0",
+  "version": "0.15.0-dev.1",
   "type": "module",
   "description": "Prisma Composer — build a Prisma App by composing Modules. Core authoring, deploy pipeline, and the service-rpc/node/nextjs authoring surfaces. The `prisma-composer` CLI lives in @prisma/composer-cli.",
   "exports": {
@@ -27,25 +27,27 @@
     "skills"
   ],
   "dependencies": {
+    "@effect/sql-d1": "4.0.0-rc.112",
+    "@effect/sql-sqlite-do": "4.0.0-rc.112",
     "@standard-schema/spec": "^1.1.0",
     "alchemy": "2.0.0-beta.74",
     "arktype": "^2.2.3",
     "c12": "^3.3.4",
-    "effect": "4.0.0-rc.111",
+    "effect": "4.0.0-rc.112",
     "esbuild": "^0.28.1",
     "@prisma/management-api-sdk": "^1.60.0"
   },
   "devDependencies": {
-    "@effect/vitest": "4.0.0-rc.111",
-    "@internal/assemble": "0.14.0",
-    "@internal/cli": "0.14.0",
-    "@internal/core": "0.14.0",
-    "@internal/foundation": "0.14.0",
-    "@internal/lowering": "0.14.0",
-    "@internal/nextjs": "0.14.0",
-    "@internal/node": "0.14.0",
-    "@internal/service-rpc": "0.14.0",
-    "@internal/tsdown-config": "0.14.0",
+    "@effect/vitest": "4.0.0-rc.112",
+    "@internal/assemble": "0.15.0-dev.1",
+    "@internal/cli": "0.15.0-dev.1",
+    "@internal/core": "0.15.0-dev.1",
+    "@internal/foundation": "0.15.0-dev.1",
+    "@internal/lowering": "0.15.0-dev.1",
+    "@internal/nextjs": "0.15.0-dev.1",
+    "@internal/node": "0.15.0-dev.1",
+    "@internal/service-rpc": "0.15.0-dev.1",
+    "@internal/tsdown-config": "0.15.0-dev.1",
     "@types/node": "^26.0.1",
     "tsdown": "^0.22.7",
     "typescript": "^6.0.3"

package/skills/prisma-composer/SKILL.md

@@ -2,7 +2,7 @@
 name: prisma-composer
 metadata:
   library: "@prisma/composer"
-  library_version: "0.14.0"
+  library_version: "0.15.0-dev.1"
 description: >-
   How to write, test, and deploy an app with Prisma Composer
   (`@prisma/composer`): declare services with `compute()` and typed
@@ -314,7 +314,7 @@ Construct it in your server entry, as in the auth example above.
 **`pnPostgres(...)`** — a Prisma Next-typed database: `load()`
 returns the typed client the framework constructs from your data contract, so
 queries like `db.orm.public.Product.all()` are compile-time checked. The
-contract is emitted from `contract.prisma` by `prisma-next contract emit` and
+contract is emitted from `contract.prisma` by `prisma contract emit` and
 wrapped once, referenced by both ends:
 
 ```ts
@@ -328,18 +328,37 @@ export const catalogData = pnContract<Contract>(contractJson);
 
 The dependency end is `deps: { db: pnPostgres(catalogData) }`. The resource
 end (inside the module that owns the database) also names the
-`prisma-next.config.ts` path, which the deploy's migration step loads to find
-`migrations/` — migrations are applied at deploy, before the service starts:
+`prisma.config.ts` path, which the deploy's migration step loads to find
+`migrations/` — committed migrations are replayed at deploy, before the
+service starts:
 
 ```ts
 const db = provision(
-  pnPostgres({ name: 'database', contract: catalogData, config: './prisma-next.config.ts' }),
+  pnPostgres({ name: 'database', contract: catalogData, config: './prisma.config.ts' }),
 );
 ```
 
 (`pnPostgres` is both ends: the contract alone is the dependency end; the
 options object is the resource end.)
 
+The deploy is replay-only: it applies the migrations committed under
+`migrations/` and never creates schema itself. Every schema change (including
+the very first schema of a new database) follows the same loop:
+
+1. Edit `contract.prisma`.
+2. `prisma contract emit` — regenerates `contract.json` + `contract.d.ts`.
+3. `prisma migration plan --name <slug>` — authors the migration into
+   `migrations/` (on an empty graph this authors the baseline,
+   empty → your schema).
+4. Commit `migrations/` with the change, then deploy. A fresh database
+   replays the whole path from empty.
+
+If no authored path reaches the target contract, the deploy (and
+`prisma-composer dev` against a stale local database) refuses with
+`MIGRATION_PATH_NOT_FOUND` and names the exits: author the missing migration
+as above, or — when iterating against a local database only — bring it along
+directly with `prisma db update`. Never skip step 3 before a deploy.
+
 See `examples/store/modules/catalog` in the prisma/composer repo for the
 complete pattern.