@shivaedev/effect-trpc 0.8.0 → 0.8.1

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 0.8.1 - 2026-10-18
+
+### Changed
+
+- Release with updated workspace dependencies.
+
 ## 0.8.0 - 2026-10-18
 
 ### Breaking

package/README.md

@@ -272,7 +272,7 @@ The mapper receives the procedure path and an `origin` of `failure` or `defect`.
 
 `instrument(effect, procedure)` wraps resolver work and can read request services. `instrumentStream(stream, procedure)` wraps subscription streams. Both receive the procedure path and kind; an Effect-instrumentation defect is redacted.
 
-Each query, mutation and subscription creates one procedure span named after its full procedure path, such as `orders.read`. Its attributes are `rpc.method` set to that path, `rpc.system: "trpc"` and `trpc.type` set to `"query"`, `"mutation"` or `"subscription"`. A span opened by the resolver is a child of that procedure span. Subscriptions also provide the caller's exact `AbortSignal` through `RequestSignal`; the resolver can observe its aborted state. The [procedure evidence tests](src/server/procedureEvidence.spec.ts) record these spans and observe signal identity and abort through `router.createCaller` in process.
+Each query, mutation and subscription creates one procedure span named after its full procedure path, such as `orders.read`. Its attributes are `rpc.method` set to that path, `rpc.system: "trpc"` and `trpc.type` set to `"query"`, `"mutation"` or `"subscription"`. A span opened by the resolver is a child of that procedure span. Subscriptions also provide the caller's exact `AbortSignal` through `RequestSignal`; the resolver can observe its aborted state.
 
 ### Once per test suite: the real router caller
 
@@ -345,11 +345,9 @@ Import each name from its defining `@shivaedev/effect-trpc/<module>.ts`; there i
 | `server/errors.ts` | `fail`, `badRequest`, `unauthorized`, `forbidden`, `notFound`, `conflict`, `preconditionFailed`, `internalServerError` |
 | `server/rejection.ts` | `rejectWith`, `rejectionCode`, `RejectionError`, `DeclaredRejection`, `RejectWithOptions` |
 | `server/rejectionFormatter.ts` | `rejectionFormatter`, `withRejection`, `RejectionData`, `RejectionErrorShape` |
-| `rejectionDecoding.ts`, `rejectionDecoding.ts` | `rejectionOf`, `decodeRejection`, `EncodedRejection` |
+| `rejectionDecoding.ts` | `rejectionOf`, `decodeRejection`, `EncodedRejection` |
 | `server/testing/caller.ts` | `makeEffectCaller`, `makeEffectCallerFactory`, `EffectCaller`, `EffectCallerFactory` |
 | `server/testing/vitest.ts` | `makeTrpcIt`, `makeTrpcHarnessIt` |
-| `server/testing/types.ts` | `CallerOptions`, `CallerResult`, `MakeTrpcItOptions`, `MakeTrpcHarnessItOptions`, `TrpcIt`, `TrpcTest`, `TrpcTester`, `TrpcHarnessIt`, `TrpcHarnessTest`, `TrpcHarnessTester` |
-| `server/testing/AnyTestLayer.ts` | `AnyTestLayer` |
 
 `rejectWith` removes the declared schema types from the Effect's error channel and adds `RejectionError`.
 
@@ -372,6 +370,4 @@ The Vitest dependency is optional unless you import the testing modules. The app
 await runtime.dispose();
 ```
 
-Choose an application server and tRPC transport separately. The rejection tests exercise tRPC's fetch handler and client in process; the cancellation test exercises a caller signal and Stream iterator. Those checks do not establish deployed HTTP or WebSocket disconnect behavior through a host or proxy. Test that boundary in the consuming application.
-
-For the package's design priorities, read [north star](https://github.com/ShivaeDev/platform/blob/main/packages/effect-trpc/docs/north-star.md). Implementation status, next work and maintainer questions live in the [roadmap](https://github.com/ShivaeDev/platform/blob/main/packages/effect-trpc/docs/roadmap.md).
+Choose an application server and tRPC transport separately. The adapter's cancellation path starts from the caller's abort signal; test deployed HTTP or WebSocket disconnect behavior through your host or proxy in the consuming application.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shivaedev/effect-trpc",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "Effect-native procedures and testing for tRPC",
   "homepage": "https://github.com/ShivaeDev/platform/tree/main/packages/effect-trpc#readme",
   "bugs": {
@@ -38,24 +38,22 @@
     "!src/**/*.spec.ts",
     "!src/**/test-support",
     "CHANGELOG.md",
-    "docs",
     "README.md"
   ],
   "dependencies": {
-    "@shivaedev/effect-test": "0.6.0"
+    "@shivaedev/effect-test": "0.7.0"
   },
   "devDependencies": {
     "@effect/vitest": "4.0.4",
     "@shivaedev/effect-contract": "0.5.1",
-    "@shivaedev/quality": "0.25.0",
-    "@shivaedev/test-story": "0.7.1",
+    "@shivaedev/quality": "0.27.1",
+    "@shivaedev/test-story": "0.11.0",
     "@trpc/client": "11.19.0",
     "@trpc/server": "11.19.0",
     "@types/node": "24.19.2",
-    "@typescript/native": "npm:typescript@7.0.2",
     "effect": "4.0.4",
     "superjson": "2.2.6",
-    "typescript": "npm:@typescript/typescript6@6.0.2",
+    "typescript": "7.0.2",
     "vitest": "5.0.3"
   },
   "peerDependencies": {

package/docs/north-star.md

@@ -1,48 +0,0 @@
-# The north star
-
-## The problem
-
-A tRPC application has a Promise boundary at every procedure. An Effect application has a different set of obligations inside that boundary: a service must be provided, a typed failure must remain distinguishable from a defect, a request must carry its own identity, and a scoped resource must live until its work ends. Handwritten adapters repeat this work at every feature and make it easy to weaken one obligation while fixing another.
-
-The package gives tRPC applications one small bridge. An application supplies its runtime once. A request Layer turns the context tRPC middleware produced into Effect services. A procedure yields those services and returns a value or a Stream. Schema describes the data boundary; an explicitly declared rejection describes the failure data a client can understand.
-
-This is the integration path for applications that use tRPC. Native Effect queries and commands belong to `effect-contract`; native request identity and server middleware belong to the `platform` RPC modules. Sharing a rejection schema across transports is useful. Making tRPC a requirement of the native framework is not.
-
-## What good looks like
-
-### Effects keep their meaning
-
-A procedure's generator is ordinary Effect work. Its service requirements must be supplied by the application runtime or request Layer; unavailable requirements must not disappear into a cast. Schema's encoded and decoded sides stay visible to both the caller and resolver. Input and output are decoders, so the resolver sees decoded input and produces encoded output.
-
-Resources keep the lifetime their work needs. A query or mutation has request work; a subscription has a Stream whose consumption owns its resources. Interruption belongs to that work too. Tests observe both the interruption and the finalizer, not just a returned cancellation error.
-
-### Requests and failures cross deliberately
-
-A tRPC context value becomes a service in a request Layer. Middleware remains the place to establish or refine that context. The adapter does not invent an authentication policy, a global current user or a second request-context vocabulary.
-
-Failure data crosses only by an explicit choice. A declared Schema rejection is data a client may decode and act on. A `TRPCError` is an explicit transport response. An application mapper may expose another known error. An unlisted failure or defect is an internal error, not an accidental serialization of database or infrastructure details.
-
-An invalid input and an application rejection are different events. The formatter's reserved `invalidInput` mark allows a client to distinguish them while keeping field-error data in one location. Declared failures must not be able to forge that mark.
-
-### tRPC and Effect remain recognizable
-
-tRPC owns routers, middleware, metadata and host transports. Effect owns services, Layers, Streams and the error channel. The adapter removes repetitive conversion at their boundary; it does not replace either side with its own framework.
-
-Tests use the router's real caller and an Effect-shaped view of it. Application fixtures can surround that caller, and test services can replace matching runtime services. The shared `effect-test` runner owns clocks and test lifecycle so this package does not maintain another implementation of them.
-
-## Trade-offs
-
-The order is Effect types, scope and interruption; deliberate request and error boundaries; tRPC interoperability; then convenience. A helper that saves a few lines but makes unavailable services compile or lets a Stream outlive its resource scope loses. A richer public error that has not been declared loses to a redacted error. A feature needing tRPC middleware should use that middleware before adding another hook to this package.
-
-Test coverage limits the wording of guarantees. In-process HTTP serialization is valuable evidence for rejection encoding, but it cannot establish a production proxy's disconnect behavior. A caller signal and finalizer test establishes that path, not all hosts and transports. Application adoption and deployment validation stay with the framework and consuming application.
-
-## What stays outside
-
-- A replacement for native `effect-contract` queries and commands.
-- A router, HTTP server, WebSocket server or transport selection policy.
-- Authentication, authorization, user-facing error wording and transaction policy.
-- A client cache, form state engine or automatic invalidation protocol.
-- A second Effect runtime owner or test runner.
-- An implied guarantee about deployed cancellation based only on local fixtures.
-
-Local implementation status, next work and maintainer decisions are in [the roadmap](./roadmap.md).

package/docs/roadmap.md

@@ -1,33 +0,0 @@
-# Roadmap
-
-This file owns `effect-trpc` implementation status and local next work. The [framework roadmap](https://github.com/ShivaeDev/platform/blob/main/docs/framework/roadmap.md) owns composed application fixtures, adoption and deployment validation. A library test is not application adoption evidence.
-
-## Built
-
-- Generator queries and mutations over an application runtime and request services, including context supplied by tRPC middleware and request-Layer extensions that consume base services. `src/server/adapter.test.ts` covers runtime execution; `src/server/EffectProcedureBuilder.typecheck.test.ts` rejects missing services.
-- Effect Schema input and output decoding with encoded/decoded caller and resolver types. Adapter runtime tests and procedure type tests cover the distinction, including subscription output decoding.
-- Stream subscriptions with request services, scoped finalizers and interruption when a caller signal aborts. `src/server/adapter.test.ts` observes values, stream instrumentation and finalization; `src/server/internal/runtime.test.ts` covers pure interruption's transport error.
-- Procedure spans named after the full path with `rpc.method`, `rpc.system: "trpc"` and `trpc.type`, including resolver-child parenting for queries, mutations and subscriptions. The [procedure evidence tests](../src/server/procedureEvidence.spec.ts) use a recording Tracer and also observe the exact caller signal through `RequestSignal`, its aborted state and subscription finalization. The [adapter tests](../src/server/adapter.test.ts) observe Effect instrumentation with request services and stream instrumentation with procedure path and kind.
-- Explicit tRPC errors, application error mapping and redaction of unmapped failures and defects. Adapter/runtime tests cover resolver, request-Layer, mapper and Effect-instrumentation defects; `src/server/httpRejections.spec.ts` checks opaque serialized failures.
-- Tagged declared rejection encoding, taxonomy code mapping, custom code selection and formatter composition. `src/server/rejection.test.ts` and `src/server/httpRejections.spec.ts` cover fields, messages, encodings, HTTP statuses and mixed batches.
-- Input-validation field paths and the reserved `invalidInput` mark. `src/server/inputRejections.spec.ts` covers dotted paths, array indexes, whole-input issues and stripping forged marks; `src/server/rejection.typecheck.test.ts` rejects reserved fields.
-- Client rejection reading and schema decoding, including malformed carriers and unknown tags. HTTP rejection tests and rejection type tests cover values, class instances and synchronous decoder requirements.
-- Reuse of `effect-contract` operation error schemas with generated and reused rejection classes. `src/server/contractRejections.spec.ts` also checks opaque failures for an operation without declared rejections.
-- An Effect-shaped caller and application-defined test harness built on `effect-test`. `src/server/testing/vitest.test.ts` covers runtime service overrides, alternate contexts, table cases and harness services; its type tests preserve caller and harness types.
-
-## Next
-
-1. Add a representative real-host transport cancellation fixture when a consumer selects that transport. Observe query and subscription interruption and resource release; keep proxy/deployment acceptance with the consuming application.
-2. Exercise test-harness setup inside the `around` wrapper and Layer acquisition lifetime through this adapter if consumers rely on that composition. The shared runner owns the implementation; adapter tests should observe the composition they promise.
-
-These are draft priorities, subject to the maintainer's investment decision below.
-
-## Questions the maintainer owns
-
-- Should the package receive new adapter features, or focus on compatibility and stronger boundary evidence for tRPC consumers? The draft next work favors evidence for existing behavior. The root package paths establish its purpose but do not set its investment order.
-- Which real host and tRPC transport should be the first cancellation fixture? Caller-signal tests and in-process fetch serialization do not decide a deployment transport.
-- Should `RequestSignal` become a uniform service for queries and mutations as well as subscriptions? It is currently supplied by the subscription handler; expanding that boundary is an API/behavior decision, not documentation work.
-
-## Evidence boundaries
-
-The HTTP rejection tests call tRPC's fetch handler in process with its actual client and transformer. Subscription cancellation uses `router.createCaller` with an abort signal and observes its iterator and finalizer. Neither is proof of a network server, WebSocket disconnect, reverse proxy, SSR or mobile lifecycle. Broader composed fixtures and deployment acceptance belong to the framework roadmap and the adopting application.