@prisma/composer 0.14.0 → 0.15.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@prisma/composer",
3
- "version": "0.14.0",
3
+ "version": "0.15.0",
4
4
  "type": "module",
5
5
  "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.",
6
6
  "exports": {
@@ -27,25 +27,27 @@
27
27
  "skills"
28
28
  ],
29
29
  "dependencies": {
30
+ "@effect/sql-d1": "4.0.0-rc.112",
31
+ "@effect/sql-sqlite-do": "4.0.0-rc.112",
30
32
  "@standard-schema/spec": "^1.1.0",
31
33
  "alchemy": "2.0.0-beta.74",
32
34
  "arktype": "^2.2.3",
33
35
  "c12": "^3.3.4",
34
- "effect": "4.0.0-rc.111",
36
+ "effect": "4.0.0-rc.112",
35
37
  "esbuild": "^0.28.1",
36
38
  "@prisma/management-api-sdk": "^1.60.0"
37
39
  },
38
40
  "devDependencies": {
39
- "@effect/vitest": "4.0.0-rc.111",
40
- "@internal/assemble": "0.14.0",
41
- "@internal/cli": "0.14.0",
42
- "@internal/core": "0.14.0",
43
- "@internal/foundation": "0.14.0",
44
- "@internal/lowering": "0.14.0",
45
- "@internal/nextjs": "0.14.0",
46
- "@internal/node": "0.14.0",
47
- "@internal/service-rpc": "0.14.0",
48
- "@internal/tsdown-config": "0.14.0",
41
+ "@effect/vitest": "4.0.0-rc.112",
42
+ "@internal/assemble": "0.15.0",
43
+ "@internal/cli": "0.15.0",
44
+ "@internal/core": "0.15.0",
45
+ "@internal/foundation": "0.15.0",
46
+ "@internal/lowering": "0.15.0",
47
+ "@internal/nextjs": "0.15.0",
48
+ "@internal/node": "0.15.0",
49
+ "@internal/service-rpc": "0.15.0",
50
+ "@internal/tsdown-config": "0.15.0",
49
51
  "@types/node": "^26.0.1",
50
52
  "tsdown": "^0.22.7",
51
53
  "typescript": "^6.0.3"
@@ -2,7 +2,7 @@
2
2
  name: prisma-composer
3
3
  metadata:
4
4
  library: "@prisma/composer"
5
- library_version: "0.14.0"
5
+ library_version: "0.15.0"
6
6
  description: >-
7
7
  How to write, test, and deploy an app with Prisma Composer
8
8
  (`@prisma/composer`): declare services with `compute()` and typed
@@ -314,7 +314,7 @@ Construct it in your server entry, as in the auth example above.
314
314
  **`pnPostgres(...)`** — a Prisma Next-typed database: `load()`
315
315
  returns the typed client the framework constructs from your data contract, so
316
316
  queries like `db.orm.public.Product.all()` are compile-time checked. The
317
- contract is emitted from `contract.prisma` by `prisma-next contract emit` and
317
+ contract is emitted from `contract.prisma` by `prisma contract emit` and
318
318
  wrapped once, referenced by both ends:
319
319
 
320
320
  ```ts
@@ -328,18 +328,37 @@ export const catalogData = pnContract<Contract>(contractJson);
328
328
 
329
329
  The dependency end is `deps: { db: pnPostgres(catalogData) }`. The resource
330
330
  end (inside the module that owns the database) also names the
331
- `prisma-next.config.ts` path, which the deploy's migration step loads to find
332
- `migrations/` — migrations are applied at deploy, before the service starts:
331
+ `prisma.config.ts` path, which the deploy's migration step loads to find
332
+ `migrations/` — committed migrations are replayed at deploy, before the
333
+ service starts:
333
334
 
334
335
  ```ts
335
336
  const db = provision(
336
- pnPostgres({ name: 'database', contract: catalogData, config: './prisma-next.config.ts' }),
337
+ pnPostgres({ name: 'database', contract: catalogData, config: './prisma.config.ts' }),
337
338
  );
338
339
  ```
339
340
 
340
341
  (`pnPostgres` is both ends: the contract alone is the dependency end; the
341
342
  options object is the resource end.)
342
343
 
344
+ The deploy is replay-only: it applies the migrations committed under
345
+ `migrations/` and never creates schema itself. Every schema change (including
346
+ the very first schema of a new database) follows the same loop:
347
+
348
+ 1. Edit `contract.prisma`.
349
+ 2. `prisma contract emit` — regenerates `contract.json` + `contract.d.ts`.
350
+ 3. `prisma migration plan --name <slug>` — authors the migration into
351
+ `migrations/` (on an empty graph this authors the baseline,
352
+ empty → your schema).
353
+ 4. Commit `migrations/` with the change, then deploy. A fresh database
354
+ replays the whole path from empty.
355
+
356
+ If no authored path reaches the target contract, the deploy (and
357
+ `prisma-composer dev` against a stale local database) refuses with
358
+ `MIGRATION_PATH_NOT_FOUND` and names the exits: author the missing migration
359
+ as above, or — when iterating against a local database only — bring it along
360
+ directly with `prisma db update`. Never skip step 3 before a deploy.
361
+
343
362
  See `examples/store/modules/catalog` in the prisma/composer repo for the
344
363
  complete pattern.
345
364