Documentation
An opinionated architectural choice — never-rest puts Result-based railway-oriented programming at the API boundary. Whether either side uses railway style internally is up to that team; the contract assumes at least one side wants Result at the edge.
A ContractDef where handlers return Result instead of throwing. serve projects that onto HTTP. ./local runs the same contract in-process, or behind a host that already carries the operation as a string. Errors carry their cause chain across boundaries. Disclosure is graded by caller trust.
| Doc | Topic |
|---|---|
| Concepts | Railway at the boundary, HTTP and local transports, no middleware, errors as data, trust circles |
| Railway patterns | Full railway/neverthrow pattern catalogue + white-label tenant kitchen sink |
| Advanced usage | definePolicy, mid-chain composers, host wraps |
| Security boundaries | Admission order, deployment-owned controls, what never-rest does not ship |
| API reference | Every public export, signature, example — including ./local |
| Examples | Express, Next, SvelteKit, Hono, Workers, gateway, files-and-streams, cancellation, MCP stdio |
| Files and streams | JSON on the railway; multipart and SSE on the host |
| Errors as intelligence | nextStep, origin, retryable, ctx, gateway chains |
| Comparison | vs ts-rest, oRPC, tRPC, and Hono RPC |
| Migrating | 0.6 → 0.7, then ts-rest, oRPC, throwing handlers |
| MCP adapter | Contract → MCP tools; policy stays on createDispatcher |
| Type performance | Instantiation budget and CI gate |
Package: @eddy-works/never-rest · Source: project-eddy/never-rest