@shivaedev/effect-prisma 0.10.0 → 0.10.2

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## 0.10.2 - 2026-10-18
+
+### Changed
+
+- Release with updated workspace dependencies.
+
+## 0.10.1 - 2026-10-18
+
+### Changed
+
+- Release with updated workspace dependencies.
+
 ## 0.10.0 - 2026-10-18
 
 ### Breaking

package/README.md

@@ -227,7 +227,7 @@ Import the defining module; the package has no root entry point.
 | --- | --- |
 | `database.ts` | `makeDatabase<Contract>()(identifier, { contractJson })`, `DatabaseDefinition`, `DatabaseLayerOptions`. Factory options also accept an already typed `contract`. |
 | `sqlite.ts` | `makeSqliteDatabase<Contract>()(identifier, options)`, `defaultSqlitePragmas`, `SqliteDatabaseDefinition`, `SqliteDatabaseLayerOptions`. Layer options include `path` and `pragmas`. |
-| `databaseTypes.ts` | `DatabaseService<Contract, Identifier>`, `DatabaseServiceOf<typeof Database>`, `AnyDatabase`, `DatabaseIdentifier`, `DatabaseIdentifierLiteral`, `DatabaseServiceHolder`, `DefaultModels`, `SqlDatabase`, `internalContextIdentifierPrefix`. |
+| `databaseTypes.ts` | `DatabaseService<Contract, Identifier>`, `DatabaseServiceOf<typeof Database>` and their supporting types. |
 | `relation.ts` | `Relation`, `RelationQuery`, `CollectionResult`. |
 | `error.ts` | `PrismaError`, `PrismaErrorReason`, `PrismaRuntimeFailure`, `PrismaQueryFailure`, `PrismaConnectionFailure`, `isPrismaFailure`, `toPrismaError`. |
 | `testing/vitest.ts` | `makeDatabaseIt({ database, layer, clock? })`. |
@@ -238,9 +238,9 @@ Import the defining module; the package has no root entry point.
 
 The Relation surface follows Prisma Next's collections. Its typed operations include filters and ordering; `select`, `take`, `cursor`, `distinct`, `distinctOn`; `include`, `count`, `exists`, `first`; `aggregate`, `groupBy`; and create, update and delete terminals. Cursor and distinct-on types require an order first. Import boolean filter combinators such as `and`, `or`, `not` and `all` from `@prisma-next/sql-orm-client`.
 
-A `PrismaError` carries a tagged `reason`. Unique-constraint tests verify `PrismaQueryFailure` with `sqlState` and `constraint`; scope and transaction guards use `PrismaRuntimeFailure` with `code`. Unknown Promise rejections remain defects rather than becoming typed database failures.
+A `PrismaError` carries a tagged `reason`. A unique-constraint violation is a `PrismaQueryFailure` with `sqlState` and `constraint`; scope and transaction guards use `PrismaRuntimeFailure` with `code`. Unknown Promise rejections remain defects rather than becoming typed database failures.
 
-`effectDB` also exposes the declared `skip`, `skipIf`, `runIf` and `only` methods. Its options and factory accept `clock`; see the [Effect test runner](https://github.com/ShivaeDev/platform/tree/main/packages/effect-test#readme) for the shared option types and clock model.
+`makeDatabaseIt` and each `effectDB` test accept `clock`; see the [Effect test runner](https://github.com/ShivaeDev/platform/tree/main/packages/effect-test#readme) for the shared option types and clock model.
 
 ### Install and contract setup
 
@@ -258,7 +258,7 @@ prisma-next contract emit
 effect-prisma-normalize path/to/generated/contract.d.ts
 ```
 
-Normalization replaces supported PostgreSQL timestamp declarations with `Date`, preserves other fields and can run twice. An unsupported timestamp declaration fails without overwriting the generated file. PostgreSQL timestamp and timestamp-with-time-zone fields accept and return JavaScript `Date` values; the tests exercise writes, reads and equality filters. SQLite `DateTime` declarations already use `Date` and do not need this PostgreSQL step.
+Normalization replaces supported PostgreSQL timestamp declarations with `Date`, preserves other fields and can run twice. An unsupported timestamp declaration fails without overwriting the generated file. PostgreSQL timestamp and timestamp-with-time-zone fields accept and return JavaScript `Date` values. SQLite `DateTime` declarations already use `Date` and do not need this PostgreSQL step.
 
 SQLite datetime text without a zone is decoded as UTC, including the `datetime('now')` column default. Text that already contains `Z` or a numeric offset is left unchanged. That generated default has whole-second precision.
 
@@ -267,9 +267,7 @@ SQLite datetime text without a zone is decoded as UTC, including the `datetime('
 - Use one exported definition and one live Layer per identifier. Duplicate identifiers or multiple simultaneous Layers for one definition are outside the supported composition.
 - Keep Database values inside their Layer and transaction lifetimes. Return rows from a transaction rather than its facade or queries.
 - PostgreSQL contracts must have one domain namespace. A model named `transaction` conflicts with the facade's transaction method.
-- SQLite needs a file-backed database; `:memory:` and an empty path are rejected. Its driver uses synchronous database calls. Treat it as a local database path and avoid coordinating separate Layers against the same file.
+- SQLite support is experimental and needs a file-backed database; `:memory:` and an empty path are rejected. Its driver uses synchronous database calls. Treat it as a local database path and avoid coordinating separate Layers against the same file.
 - One SQLite Layer serializes finite root query Effects with the entire explicit transaction lifetime. Transaction queries have a separate permit. Root Streams remain incremental; do not treat them as holding that lifetime permit.
 - Transaction Streams buffer the full result. Refine large queries before collecting them in a transaction.
 - The API excludes model variants and direct scalar aggregate shortcuts; use the typed `aggregate` callback. Prisma Next features are not automatically package guarantees.
-
-The [roadmap](https://github.com/ShivaeDev/platform/blob/main/packages/effect-prisma/docs/roadmap.md) records package status and maintainer questions. The tests distinguish real PostgreSQL behavior, file-backed SQLite behavior and controlled execution tests; PostgreSQL tests skip when their database URL is absent.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shivaedev/effect-prisma",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Effect-native PostgreSQL queries and transactions for Prisma Next",
   "homepage": "https://github.com/ShivaeDev/platform/tree/main/packages/effect-prisma#readme",
   "bugs": {
@@ -40,7 +40,6 @@
     "!src/**/*.test.ts",
     "!src/**/*.spec.ts",
     "!src/**/test-support",
-    "docs",
     "CHANGELOG.md",
     "README.md"
   ],
@@ -52,7 +51,7 @@
     "@prisma-next/sql-relational-core": "0.16.0",
     "@prisma-next/sql-runtime": "0.16.0",
     "@prisma-next/sqlite": "0.16.0",
-    "@shivaedev/effect-test": "0.6.0",
+    "@shivaedev/effect-test": "0.7.1",
     "pg": "8.23.0"
   },
   "devDependencies": {
@@ -62,13 +61,12 @@
     "@prisma-next/cli": "0.16.0",
     "@prisma-next/target-postgres": "0.16.0",
     "@prisma-next/target-sqlite": "0.16.0",
-    "@shivaedev/quality": "0.25.0",
-    "@shivaedev/test-story": "0.7.1",
+    "@shivaedev/quality": "0.27.1",
+    "@shivaedev/test-story": "0.11.1",
     "@types/node": "24.19.2",
     "@types/pg": "8.20.0",
-    "@typescript/native": "npm:typescript@7.0.2",
     "effect": "4.0.4",
-    "typescript": "npm:@typescript/typescript6@6.0.2",
+    "typescript": "7.0.2",
     "vitest": "5.0.3"
   },
   "peerDependencies": {

package/docs/north-star.md

@@ -1,47 +0,0 @@
-# North star
-
-## The problem
-
-An application with a Prisma Next contract already has a model vocabulary and generated query types. Effect services around that client still need a reliable boundary: queries must be Effects, database failures must remain inspectable, client ownership must fit a scope and a transaction must reach every participating query without passing an unrelated client through every method.
-
-Tests have the same problem. A test should exercise the generated queries and real database, then discard its writes, whether it succeeds or fails. Rebuilding that transaction harness in every application spreads the most delicate part of persistence across code that is easy to get wrong.
-
-This package owns that bridge. It serves applications that use Prisma Next while `effect-sql` owns the framework's native persistence and migration path. Prisma Classic is a separate integration: `effect-changes-prisma` binds change channels to its interactive transactions.
-
-## The ideal
-
-A generated contract becomes one exported Database definition. Application services yield it, describe queries with its models and compose ordinary Effects. A transaction provides the same definition for its body. Repositories need no public executor service and no second model declaration.
-
-A query description can be reused or branched without changing another caller's query. A query captured from the root facade finds the active transaction when executed. A value made inside a transaction cannot silently fall back to the root client after that transaction ends or cross into a sibling transaction.
-
-Types must carry the contract through filters, writes, selections and relation loading. Two databases sharing a contract still have separate identities. A convenience that loses a field type, a nullable relation or a database boundary costs more than the lines it saves.
-
-## What good looks like
-
-- One Database service is visible to application code. Its private coordination preserves Effect dependency and scope semantics.
-- Query failures preserve database information needed for a domain decision. Unrecognized failures stay defects rather than being recast as expected database errors.
-- Transaction settlement waits for in-flight work, then commits or rolls back and releases the connection. No permit is released while interrupted work is still using its connection.
-- Every branch of a query remains independent. Included queries come from the correct model, Database and transaction owner.
-- A database test drives real rows through the same public facade and rolls back afterwards. Test helpers compose with `effect-test` rather than building another runner.
-- Documentation says exactly which tests establish a claim. Controlled collection tests, SQLite tests and real PostgreSQL tests each establish their own boundary.
-
-## Trade-offs
-
-**Effect semantics before upstream coverage.** Preserve typed errors, scoped ownership and exact model types first. Add a Prisma Next feature only when its public types and lifecycle fit; excluding an operation is preferable to weakening it into a generic dynamic escape hatch.
-
-**One transaction connection before apparent parallelism.** Concurrent Effects may describe independent work, but queries on one transaction connection need coordination. A transaction Stream may buffer rows so downstream work can use that connection. That spends memory to preserve a clear lifetime and avoid a query waiting on its own occupied connection.
-
-**SQLite's engine limits before an identical performance promise.** The same facade does not make PostgreSQL and a synchronous SQLite driver equivalent. Coordinate one SQLite Layer's finite queries and transaction lifetimes; do not promise coordination across independently created clients.
-
-**One supported composition before hidden identity machinery.** Applications export and reuse one definition per identifier and provide one live Layer for it. Do not invent cross-runtime registries to make duplicate definitions look safe.
-
-## What it leaves out
-
-- Authoring application contracts, schema changes, migrations or domain repositories.
-- A new query language or a second authored model next to Prisma Next's contract.
-- Prisma Classic client adaptation, commit-bound change tracking, auth policy or a tRPC transport.
-- Nested independent rollback promises without driver savepoint support.
-- Model variants or broader upstream parity obtained by weakening public types.
-- Coordination of multiple SQLite Layers against the same file.
-
-The maintainer owns feature breadth and the backend support policy. Their open choices and the package's current work live in `roadmap.md`.

package/docs/roadmap.md

@@ -1,32 +0,0 @@
-# Roadmap
-
-This file owns effect-prisma's implementation status and backend questions. The framework roadmap owns application adoption and work that composes multiple packages; it does not repeat this package's feature checklist.
-
-## Built
-
-| Capability | Evidence |
-| --- | --- |
-| Prisma Next Database definitions and generated model types, including distinct identities for the same contract | `src/database.typecheck.test.ts`, `src/databaseTypes.typecheck.test.ts` |
-| Immutable, reusable Relations, typed filtering and selection, first/exists/count | `src/internal/relation.spec.ts`, `src/database.typecheck.test.ts` |
-| Related rows, nullable to-one values, nested/refined includes, counts and named projections | `src/database.test.ts`, `src/sqliteQueries.spec.ts`, `src/relation.typecheck.test.ts` |
-| Bulk create/update/delete and count/grouped aggregates | `src/database.test.ts`, `src/sqliteQueries.spec.ts` |
-| Commit/rollback transactions with nested reuse, context guards, query serialization and safe settlement | `src/databaseTransaction.spec.ts`, `src/sqliteTransaction.spec.ts`, `src/internal/transaction.test.ts` |
-| Reusable Streams, incremental root reads and buffered transaction reads | `src/internal/relation.spec.ts`, `src/internal/transactionConcurrency.spec.ts`, database transaction suites |
-| Typed query failures and preservation of unknown rejections as defects | `src/database.test.ts`, `src/sqlite.test.ts`, `src/internal/relation.spec.ts` |
-| PostgreSQL timestamp declarations normalized to Date without overwriting unsupported forms | `src/bin/normalize-contract.test.ts`, `src/database.test.ts`, compiler tests |
-| File-backed SQLite facade, WAL setup, UTC datetime decoding and coordinated query/transaction access | `src/sqlite.test.ts`, `src/sqliteIsolation.spec.ts`, `src/internal/sqliteDatetime.test.ts` |
-| Rollback-only transaction primitive and Vitest facade built on effect-test | `src/databaseTesting.spec.ts`, `src/sqliteTesting.spec.ts`, `src/sqliteIsolation.spec.ts` |
-
-SQLite remains experimental. PostgreSQL tests require `PLATFORM_EFFECT_PRISMA_TEST_DATABASE_URL`; a skipped PostgreSQL suite establishes no PostgreSQL behavior. Compiler tests cover cursor/distinct/distinct-on and single-row mutation types without establishing their runtime result semantics.
-
-## Next
-
-The repository does not name a next package implementation milestone. Before expanding the facade or promoting a backend, the maintainer needs to choose the intended support scope below. Framework adoption is separate work, tracked in the framework roadmap.
-
-The existing compatibility boundary is narrow: maintain the generated-contract adaptation, transaction ownership and rollback test path without making native SQL applications depend on Prisma Next.
-
-## Open questions
-
-- How much ongoing Prisma Next feature work should this compatibility path receive alongside `effect-sql`? Keeping it maintained, freezing its feature scope and expanding toward upstream parity are different commitments; the repository has not chosen between them.
-- What evidence and consumer need would promote SQLite beyond experimental support? The current facade has file-backed integration tests and coordination within one Layer, but no commitment to multi-client coordination or broader deployment guarantees.
-- Should model variants and the other excluded Prisma Next collection operations ever join this facade? The draft design prefers exact types and transaction semantics over feature breadth; the maintainer owns whether broader parity is a goal.