feat: implement caching middleware

[aqrln]

Cache middleware + annotation surface

Refs: TML-2143

Headline

Opt one read into the cache with one configurator argument:

const user = await db.User.first(
  { id },
  (meta) => meta.annotate(cacheAnnotation({ ttl: 60_000 })),
);

const recent = await db.User.take(10).all(
  (meta) => meta.annotate(cacheAnnotation({ ttl: 60_000 })),
);

// Type error: cacheAnnotation declares applicableTo: ['read']; create() fixes K = 'write'.
await db.User.create(input, (meta) => meta.annotate(cacheAnnotation({ ttl: 60_000 })));

SQL DSL keeps its existing chainable variadic — builders are not terminals, so growth happens via additional builder methods rather than additional positional args:

const plan = db.sql
  .from(tables.user)
  .select({ id: tables.user.columns.id })
  .annotate(cacheAnnotation({ ttl: 60_000 }))
  .build();

Wiring the middleware on the runtime:

const db = postgres<Contract, TypeMaps>({
  contractJson,
  url: process.env['DATABASE_URL']!,
  middleware: [createCacheMiddleware({ maxEntries: 1000 })],
});

Summary

Builds on the intercept hook + contentHash(exec) SPI from the prior PR (cache-middleware-intercept) and lands the rest of the cache-middleware project:

• A typed annotation surface on @prisma-next/framework-components: defineAnnotation / ValidAnnotations / assertAnnotationsApplicable, plus the OperationKind = 'read' | 'write' discriminator and AnnotationHandle / AnnotationValue types.
• A MetaBuilder<K> module (createMetaBuilder(kind, terminalName) factory) that ORM terminals construct and hand to a user-supplied configurator callback. Public surface is meta.annotate(annotation) with a conditional K extends Kinds ? AnnotationValue<P, Kinds> : never parameter type — no variadic-tuple inference, no load-bearing intersection.
• Lane integration on every user-facing query surface: chainable .annotate(...) on all five SQL DSL builders (variadic, kept as today), and an optional configure: (meta: MetaBuilder<K>) => void last argument on every ORM Collection / GroupedCollection terminal. Both surfaces fail closed at the type level (the SQL DSL via the variadic-tuple intersection As & ValidAnnotations<K, As>, the ORM via the conditional parameter on meta.annotate) and at runtime (via assertAnnotationsApplicable invoked by meta.annotate and by .build()).
• A new @prisma-next/middleware-cache package with cacheAnnotation, the CacheStore interface, an in-memory LRU createInMemoryCacheStore, and the cross-family createCacheMiddleware that wires intercept / onRow / afterExecute.
• A scope: 'runtime' | 'connection' | 'transaction' discriminator on RuntimeMiddlewareContext, populated by both family runtimes, used by the cache middleware to bypass non-runtime executions where caller expectations diverge from the shared cache surface.
• Demo programs (cache-demo-user, cache-demo-users, cache-demo-sql) under examples/prisma-next-demo, and a real-Postgres integration test that pins the April stop condition: a repeated annotated query is served by the middleware without invoking the driver.
• Subsystem documentation updates in docs/architecture docs/subsystems/4. Runtime & Middleware Framework.md covering the intercept lifecycle, the annotation surface, the new scope field, and the cache integration as the canonical example.

Motivation

The prior PR added the SPI — intercept, AfterExecuteResult.source, contentHash(exec) — but exposed no user-facing way to drive it. A hand-written RuntimeMiddleware could already short-circuit executions, but no product feature consumed the SPI, and there was no way for a query author to say "cache this read."

Two design constraints shaped the surface:

1. Caching a mutation has to be structurally impossible. Either the type system rejects it, or the runtime does — preferably both. Threading a per-middleware "is-this-a-mutation?" classifier through every adapter would have been correct but ad-hoc and hard to reuse.

2. The cache middleware must stay cross-family. The package may not depend on @prisma-next/sql-runtime or @prisma-next/mongo-runtime. Cache key resolution has to flow through the framework-level ctx.contentHash(exec) SPI; the cache itself can read no family-specific field of the lowered exec.

The annotation surface satisfies both: handles carry a declared applicableTo set, the MetaBuilder.annotate parameter resolves to never for inapplicable kinds, and the cache middleware reads the payload through the handle's own read(plan) rather than touching plan.meta.annotations directly. The lane-level applicability gate replaces what would otherwise be an in-middleware mutation guard.

What's in this PR

@prisma-next/framework-components — annotation surface

New module src/annotations.ts (re-exported from exports/runtime):

• type OperationKind = 'read' | 'write' — binary discrimination for now. Finer-grained kinds ('select' | 'insert' | 'update' | 'delete' | 'upsert') are deferred until a real annotation needs them.

• defineAnnotation<Payload>()(options) — curried two-step factory. The outer call takes only Payload as an explicit type argument; the inner call takes the runtime options and infers Kinds from applicableTo via a const type parameter. Returns an AnnotationHandle<Payload, Kinds> that is callable — handle(value) constructs an AnnotationValue ready to pass to a lane terminal. The handle also exposes namespace, applicableTo: ReadonlySet<Kinds>, and read(plan): Payload | undefined as own properties on the function. There is intentionally no .apply(...) method on the interface — calling the handle directly is the sole construction path.

  Currying is required because TypeScript does not support partial type-argument inference: a single-step defineAnnotation<Payload, const Kinds> form would still require both type arguments be passed explicitly (TS2558), since Payload is not inferable from anything in the options. Splitting the call separates the explicit-from-inferred step at the cost of one extra () at the definition site.

• AnnotationValue<Payload, Kinds> — branded with __annotation: true; carries namespace, value: Payload, and applicableTo: ReadonlySet<Kinds>. Stored verbatim in plan.meta.annotations[namespace]. The brand is what handle.read checks before returning, so framework-internal metadata under the same namespace key (e.g. the SQL emitter's meta.annotations.codecs map) does not surface as a user-handle read.

• ValidAnnotations<K, As> — mapped tuple type that resolves each element of As to never when its declared Kinds does not include K. Consumed by SQL DSL .annotate(...) builders on their variadic ...annotations parameter. The TSDoc records the discovery surfaced during M2: builders must use As & ValidAnnotations<K, As>, not just ValidAnnotations<K, As> — without the intersection, TypeScript's variadic-tuple inference picks an As that makes the call valid even when the gated tuple would contain never. The intersection pins As to the actual call-site tuple AND requires assignability to the gated form. The ORM MetaBuilder deliberately sidesteps this trick by taking one annotation per call (no variadic-tuple inference involved).

• assertAnnotationsApplicable(annotations, kind, terminalName) — runtime gate. Throws RUNTIME.ANNOTATION_INAPPLICABLE with structured details (namespace, terminalName, kind, applicableTo) on the first inapplicable annotation. Belt-and-suspenders for callers that bypass the type gate via as any / dynamic invocation.

Coverage: 23 runtime tests + 24 type-level tests in framework-components/test/annotations.{test.ts,types.test-d.ts} covering handle metadata, value construction, read/write isolation, the gate type's element-wise behavior, and the runtime check's error paths.

@prisma-next/framework-components — MetaBuilder<K> module

New module src/meta-builder.ts (re-exported from exports/runtime):

export interface MetaBuilder<K extends OperationKind> {
  annotate<P, Kinds extends OperationKind>(
    annotation: K extends Kinds ? AnnotationValue<P, Kinds> : never,
  ): this;
}

export interface LaneMetaBuilder<K extends OperationKind> extends MetaBuilder<K> {
  readonly annotations: ReadonlyMap<string, AnnotationValue<unknown, OperationKind>>;
}

export function createMetaBuilder<K extends OperationKind>(
  kind: K,
  terminalName: string,
): LaneMetaBuilder<K>;

• The conditional K extends Kinds ? AnnotationValue<P, Kinds> : never parameter type collapses to never for inapplicable annotations, so meta.annotate(writeOnly) on a 'read' builder fails to compile at the call site. No variadic-tuple inference, no As & ValidAnnotations<K, As> intersection — TypeScript infers Kinds from the annotation argument, then evaluates the conditional.
• annotate(...) validates eagerly via assertAnnotationsApplicable([annotation], this.kind, this.terminalName) so cast-bypass cases (as any) throw RUNTIME.ANNOTATION_INAPPLICABLE at the configurator call site rather than later in the terminal.
• annotate returns this, so chaining (meta.annotate(a).annotate(b)) and block-body callbacks ((meta) => { meta.annotate(a); meta.annotate(b); }) both work.
• MetaBuilder<K> is the public-facing view (only annotate); LaneMetaBuilder<K> is the lane-side view that exposes the recorded annotations map. Lane terminals construct one via createMetaBuilder, hand it to the user as MetaBuilder<K>, then read meta.annotations after the callback returns.

Coverage: 10 runtime tests + 17 type-level tests in framework-components/test/meta-builder.{test.ts,types.test-d.ts}.

@prisma-next/framework-components — scope on RuntimeMiddlewareContext

RuntimeMiddlewareContext gains a scope: 'runtime' | 'connection' | 'transaction' field. SqlRuntimeImpl populates 'runtime' for top-level execute, derives a new context with 'connection' for connection.execute, and 'transaction' for transaction.execute and withTransaction. MongoRuntimeImpl populates 'runtime' for now (no transaction surface yet). Coverage in packages/2-sql/5-runtime/test/scope-plumbing.test.ts.

The cache middleware uses this to bypass caching in non-runtime scopes — read-after-write coherence inside a transaction is the caller's expectation, and connection-scoped executions can step outside the shared cache surface in ways the middleware can't reason about.

SQL DSL — .annotate(...) on all five builders

packages/2-sql/4-lanes/sql-builder/src/runtime/builder-base.ts, query-impl.ts, and mutation-impl.ts get an .annotate(...) method on every builder:

• SelectQueryImpl → kind 'read' (via QueryBase)
• GroupedQueryImpl → kind 'read' (via QueryBase)
• InsertQueryImpl → kind 'write'
• UpdateQueryImpl → kind 'write'
• DeleteQueryImpl → kind 'write'

Signature on each builder:

annotate<As extends readonly AnnotationValue<unknown, OperationKind>[]>(
  ...annotations: As & ValidAnnotations<K, As>
): this

Behavior:

• Type-level: read builders reject write-only annotations and vice versa; both-kind annotations are accepted on every builder; negative cases fail to compile.
• Runtime: assertAnnotationsApplicable runs at .annotate() call time, not deferred to .build(), so casts / any / dynamic invocations fail fast.
• Chainable in any position. Multiple .annotate() calls compose; duplicate namespaces last-write-win.
• Annotations merge into plan.meta.annotations at .build() time alongside the framework-internal codecs map under its reserved namespace. Reserved keys win over user annotations under the same key (defensive — see the reserved-namespace policy on defineAnnotation).

Plumbing: BuilderState gains userAnnotations: ReadonlyMap<string, AnnotationValue<unknown, OperationKind>>; mutation builders carry their own private field and thread it through .where() / .returning() clones. buildQueryPlan accepts an optional userAnnotations parameter and composes the final meta.annotations from both maps. A small mergeWriteAnnotations helper deduplicates the validate-clone-set pattern across the three mutation builders.

Why a chainable variadic on the SQL DSL but a callback on the ORM: builders are not terminals — they return new builders that participate in further chaining — and growth happens via additional builder methods (.cache(...), .tag(...)) rather than additional positional arguments to .annotate() itself. The user-facing concern that drove the ORM redesign (a variadic tail on a terminal forecloses on adding new positional or named per-call options) does not apply at the builder layer. Keeping the SQL DSL chainable also keeps existing call sites untouched.

Coverage: 28 runtime tests + 26 type-level tests in sql-builder/test/runtime/annotate.test.ts and sql-builder/test/playground/annotate.test-d.ts, exercising every builder kind plus chain positions, immutability, namespace coexistence, and the runtime gate.

ORM Collection / GroupedCollection — meta-callback configurator on terminals

Per the spec, annotations attach via the terminal's optional configurator argument only — there is no chainable .annotate() on Collection. That scope cut keeps the per-terminal kind binding clean and structurally prevents passing read annotations to mutations.

Read terminals updated:

• Collection.all and Collection.first accept configure?: (meta: MetaBuilder<'read'>) => void as their last argument.
• Collection.aggregate and GroupedCollection.aggregate likewise.

Write terminals updated:

• create / createAll / createCount
• update / updateAll / updateCount
• delete / deleteAll / deleteCount
• upsert

Each accepts configure?: (meta: MetaBuilder<'write'>) => void as its last argument after the existing leading arguments. For terminals that issue both a "matching" read and a write statement (updateCount, deleteCount), annotations attach only to the write — the matching read is internal and not user-facing.

Why a callback rather than a variadic:

• Future-proof terminal signatures. A terminal whose last positional argument is a variadic of annotations cannot grow new positional or named per-call options without a breaking change. There is no future shape db.orm.User.find(input, { … }, ann1, ann2) to evolve into without churning every call site. Adding a method to MetaBuilder<K> (meta.timeout(...), meta.tag(...), meta.cancellation(signal)) is a non-breaking surface extension.
• Drops a load-bearing TypeScript trick. A variadic terminal needs the As & ValidAnnotations<K, As> intersection to reject inapplicable annotations through variadic-tuple inference. The callback hands one annotation at a time to meta.annotate(...), which uses an ordinary conditional constraint — no intersection, no documented "load-bearing trick" on the ORM lane.
• Removes the isAnnotationValue brand-discriminator inside first. The variadic shape disambiguated first(filterOrAnnotation, ...rest) at runtime by checking whether the leading argument was a branded annotation. With annotations in the configurator slot, first(filter?, configure?) is unambiguous: positional 1 is the filter, positional 2 is the configurator. The dispatch shrinks; the isAnnotationValue helper is gone.
• Aligns with the rest of the ORM client's idioms. .where((model) => …), .include((collection) => …), .aggregate((agg) => …), .having((having) => …) already use callback configurators.

first shape note: the existing positional dispatch is preserved — a single function arg is interpreted as a filter callback, matching shipped semantics. To attach a configurator without a filter, pass undefined as the first argument: first(undefined, (meta) => …). The runtime cannot disambiguate "single function = filter vs. single function = configurator" without invoking it; explicit undefined keeps positional dispatch unambiguous and side-effect-free.

Plumbing:

• CollectionState retains userAnnotations: ReadonlyMap<string, AnnotationValue<unknown, OperationKind>>. Empty on a fresh state; populated transiently by terminal calls just before dispatch.
• Two private helpers replace the old variadic-array helpers:
  • #withAnnotationsFromMeta(configure, terminalName) for state-driven reads (all, first): constructs a MetaBuilder<'read'>, invokes the configurator, folds meta.annotations into state.userAnnotations, and returns a clone (or the receiver unchanged when no configurator was supplied or it recorded nothing).
  • #collectAnnotationsFromMeta<K>(configure, kind, terminalName) for the post-wrap path (aggregate and all writes): same construction, returns the recorded map (or undefined when empty) for mergeUserAnnotations to consume.
• The runtime gate fires inside meta.annotate(...) itself, so terminals do not re-validate after the callback returns.
• buildOrmQueryPlan accepts an optional userAnnotations parameter and merges into plan.meta.annotations alongside the reserved codecs map. compileSelect, compileSelectWithIncludeStrategy, and compileRelationSelect thread state.userAnnotations through.
• Write terminals use a post-wrap mergeUserAnnotations(compiled, annotationsMap) on the compiled mutation plan(s), mirroring the aggregate path. For terminals that produce multiple plans (createAll's compileInsertReturningSplit, createCount's compileInsertCountSplit), the map applies to every plan in the array.
• update() / delete() preserve their this-typed receivers (TypeScript's this: State['hasWhere'] extends true ? Collection<...> : never trick gates at the type level); the receiver is narrowed via cast just once inside the method body.

Two paths intentionally do not yet thread annotations into their constituent SQL statements: nested-mutation paths (executeNestedCreateMutation, executeNestedUpdateMutation) and MTI variant create paths (#executeMtiCreate). Both are documented as follow-ups in projects/middleware-intercept-and-cache/follow-ups.md. Neither blocks the April stop condition: cacheAnnotation is read-only, so writes don't matter; the type-level gate already prevents read-only annotations on writes regardless.

Coverage: 39 runtime tests + 56 type-level tests in sql-orm-client/test/annotations.{test.ts,types.test-d.ts} covering happy paths, runtime cast bypasses for at least one terminal in each family, multi-namespace coexistence, chain survival, and per-terminal type rejection.

@prisma-next/middleware-cache — new package

Layout mirrors middleware-telemetry. Registered in architecture.config.json under extensions/integrations/runtime so pnpm lint:deps validates it. Depends only on @prisma-next/framework-components — no SQL or Mongo runtime dependency, which is the cross-family constraint enforced by ADR 204.

• cacheAnnotation (src/cache-annotation.ts): defineAnnotation<CachePayload>()({ namespace: 'cache', applicableTo: ['read'] }). CachePayload = { ttl?: number; skip?: boolean; key?: string }.

• CacheStore and createInMemoryCacheStore (src/cache-store.ts): pluggable { get, set } interface plus a default in-process LRU-with-TTL store backed by a Map. Iteration order is LRU; both set and get bump recency. Expired entries drop on access without counting against maxEntries on the next write. The clock is injectable so tests verify TTL expiry without real-time waits. Default maxEntries: 1000. The default in-memory store is per-process and not coherent across replicas — users who need a shared cache pass a custom CacheStore (Redis, Memcached, etc.).

• createCacheMiddleware (src/cache-middleware.ts): wires three RuntimeMiddleware hooks.

  • intercept: bypass when ctx.scope !== 'runtime', when cacheAnnotation is absent, when skip: true, or when ttl is missing. Otherwise resolve the key (per-query key override > ctx.contentHash(exec)) and probe the store. On a hit, log middleware.cache.hit and return the cached rows. On a miss, record a per-exec PendingMiss in a private WeakMap and log middleware.cache.miss.
  • onRow: append each driver row to the pending buffer for that exec.
  • afterExecute: commit the buffer to the store iff completed === true AND source === 'driver'. Cleans up the WeakMap entry in all branches so a failed or middleware-served execution leaves no residue.

  Cross-family by construction: no familyId / targetId, reads keys from ctx.contentHash populated by the family runtime.

Coverage:

• test/cache-middleware.test.ts — opt-in semantics, bypass branches, hit/miss flow, pending-buffer correctness, scope guard, store interaction, telemetry events.
• test/cache-store.test.ts — LRU eviction, TTL expiry under injected clock, recency bumps.
• test/cache-key.test.ts — default contentHash path, per-query key override (asserts contentHash is not invoked), Mongo parity with a mock context whose contentHash returns a Mongo-style string.
• test/cache-annotation.{test.ts,types.test-d.ts} — handle round-trip and lane-kind gating.

Real-Postgres integration test

test/integration/test/cross-package/middleware-cache.test.ts covers the four April stop-condition scenarios end-to-end:

• Stop condition. A repeated annotated SQL DSL query is served from cache. Spy on driver.execute and assert call count does not increase between miss and hit.
• Composition with beforeCompile. An "active users only" rewriter prepends a predicate; the cache key reflects the rewritten lowered SQL. Two runtimes (with vs. without the rewriter) sharing one CacheStore land in distinct slots.
• Composition with telemetry. afterExecute fires on miss and hit; source round-trips as 'driver' on miss and 'middleware' on hit. beforeExecute is suppressed on the intercepted hit path.
• Concurrency. Two parallel executes of the same plan produce correct, identical results without cross-talk via the per-exec WeakMap buffer; a third sequential call hits the cache.

Plus opt-in regression tests: un-annotated queries always hit the driver; skip: true bypasses the cache.

Demo additions

examples/prisma-next-demo:

• src/orm-client/find-user-by-id-cached.ts — db.User.first({ id }, (meta) => meta.annotate(cacheAnnotation({ ttl, skip }))).
• src/orm-client/get-users-cached.ts — db.User.take(n).all((meta) => meta.annotate(cacheAnnotation({ ttl, key? }))), demonstrating the per-query key override.
• src/queries/get-users-cached.ts — db.sql.user.select(...).annotate(cacheAnnotation({ ttl })).build() (SQL DSL chainable form).
• Three new CLI commands in src/main.ts: cache-demo-user, cache-demo-users, cache-demo-sql. Each runs the same query twice and prints first-call vs. second-call timings to make the cache short-circuit visible.
• test/repositories.integration.test.ts extends with a driver-spy assertion on the cache helpers, mirroring the cross-package integration test on the demo's own runtime config.

Documentation

docs/architecture docs/subsystems/4. Runtime & Middleware Framework.md:

• Updated runWithMiddleware lifecycle to start with the intercept step, with hit-path semantics for skipping beforeExecute / runDriver / onRow.
• New "Intercepting Execution" section covering chain semantics, hit path, row shape, verification ordering, error path, the WeakMap-correlated plan-identity invariant, and family-agnostic construction with the cache middleware as the canonical example.
• New "Annotations" subsection: OperationKind, defineAnnotation, ValidAnnotations<K, As>, the split lane integration (SQL DSL chainable variadic; ORM meta-callback via MetaBuilder<K> from createMetaBuilder), the runtime applicability check, plan.meta.annotations storage, and reserved namespaces.
• Documented the contentHash(exec) and scope fields on RuntimeMiddlewareContext.
• Updated lifecycle sequence diagram to branch on intercept hit vs. driver path and show source: 'middleware' | 'driver' on afterExecute.
• Refreshed the Testing Strategy with the intercept matrix, annotation surface, family contentHash impls, cache middleware unit + integration coverage, and SQL runtime scope plumbing.

Updated projects/middleware-intercept-and-cache/spec.md and plan.md to reflect the curried defineAnnotation<Payload>()({ ... }) form, the callable-handle convention (cacheAnnotation({ ttl }) rather than cacheAnnotation.apply({ ttl })), and the meta-callback ORM API. api-revision-meta-callback.md records the design delta from the original variadic-on-terminal shape to the configurator. follow-ups.md captures the deferred work: nested-mutation annotation threading, MTI variant create paths, and the wider read-terminal annotation surface beyond all / first / aggregate.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

Run ID: 07128b10-3eff-44b7-998d-028e36f7a57e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch cache-middleware-impl

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new]

Open in StackBlitz

@prisma-next/mongo-runtime

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-runtime@385

@prisma-next/family-mongo

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/family-mongo@385

@prisma-next/sql-runtime

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-runtime@385

@prisma-next/family-sql

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/family-sql@385

@prisma-next/extension-arktype-json

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/extension-arktype-json@385

@prisma-next/middleware-cache

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/middleware-cache@385

@prisma-next/middleware-telemetry

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/middleware-telemetry@385

@prisma-next/mongo

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo@385

@prisma-next/extension-paradedb

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/extension-paradedb@385

@prisma-next/extension-pgvector

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/extension-pgvector@385

@prisma-next/postgres

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/postgres@385

@prisma-next/sql-orm-client

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-orm-client@385

@prisma-next/sqlite

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sqlite@385

@prisma-next/target-mongo

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/target-mongo@385

@prisma-next/adapter-mongo

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/adapter-mongo@385

@prisma-next/driver-mongo

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/driver-mongo@385

@prisma-next/contract

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/contract@385

@prisma-next/utils

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/utils@385

@prisma-next/config

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/config@385

@prisma-next/errors

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/errors@385

@prisma-next/framework-components

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/framework-components@385

@prisma-next/operations

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/operations@385

@prisma-next/ts-render

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/ts-render@385

@prisma-next/contract-authoring

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/contract-authoring@385

@prisma-next/ids

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/ids@385

@prisma-next/psl-parser

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/psl-parser@385

@prisma-next/psl-printer

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/psl-printer@385

@prisma-next/cli

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/cli@385

@prisma-next/emitter

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/emitter@385

@prisma-next/migration-tools

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/migration-tools@385

prisma-next

npm i https://pkg.pr.new/prisma/prisma-next@385

@prisma-next/vite-plugin-contract-emit

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/vite-plugin-contract-emit@385

@prisma-next/mongo-codec

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-codec@385

@prisma-next/mongo-contract

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-contract@385

@prisma-next/mongo-value

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-value@385

@prisma-next/mongo-contract-psl

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-contract-psl@385

@prisma-next/mongo-contract-ts

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-contract-ts@385

@prisma-next/mongo-emitter

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-emitter@385

@prisma-next/mongo-schema-ir

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-schema-ir@385

@prisma-next/mongo-query-ast

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-query-ast@385

@prisma-next/mongo-orm

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-orm@385

@prisma-next/mongo-query-builder

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-query-builder@385

@prisma-next/mongo-lowering

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-lowering@385

@prisma-next/mongo-wire

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/mongo-wire@385

@prisma-next/sql-contract

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-contract@385

@prisma-next/sql-errors

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-errors@385

@prisma-next/sql-operations

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-operations@385

@prisma-next/sql-schema-ir

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-schema-ir@385

@prisma-next/sql-contract-psl

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-contract-psl@385

@prisma-next/sql-contract-ts

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-contract-ts@385

@prisma-next/sql-contract-emitter

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-contract-emitter@385

@prisma-next/sql-lane-query-builder

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-lane-query-builder@385

@prisma-next/sql-relational-core

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-relational-core@385

@prisma-next/sql-builder

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/sql-builder@385

@prisma-next/target-postgres

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/target-postgres@385

@prisma-next/target-sqlite

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/target-sqlite@385

@prisma-next/adapter-postgres

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/adapter-postgres@385

@prisma-next/adapter-sqlite

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/adapter-sqlite@385

@prisma-next/driver-postgres

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/driver-postgres@385

@prisma-next/driver-sqlite

npm i https://pkg.pr.new/prisma/prisma-next/@prisma-next/driver-sqlite@385

commit: f99e5b0