What these are
A collection of small TypeScript packages that agree with each other, built on what the web platform already provides.
Last updated 2026-09-21
@sdxc is 60 packages published under one npm scope. They were written for
the same author's applications and kept in one repository, which is why they agree with each
other: the same idea of what a failure is, the same idea of what validation looks like, the
same idea of where the framework goes.
What they have in common
The platform is the baseline. A package takes a Request and answers with a Response,
hashes through Web Crypto, formats through Intl, and describes a schema through Standard
Schema. Where the platform has an answer, that answer is the API; a shim exists only where it
does not.
Failure is a value. Every fallible entry point returns a Result rather than throwing, so
a failure is something the type system makes you look at. A parse failure also carries the
position it happened at, which is what turns "invalid input" into a line number.
Nothing arrives that you did not ask for. 31 of the 60 have no dependency outside the collection at all, and the ones that do name it in their README. Subpath exports keep the parts of a package you never import out of your bundle.
They are written for Remix, and most work without it. 23 target Remix
directly — that is the framework these are built for and the one they are proven in, across the
applications listed on the showcase. The other 37 depend on no framework
and run anywhere fetch does. Where a package needs both, the framework binding sits under its
own subpath, so the core stays importable on its own.
What they are not
They are not a framework. There is no CLI that scaffolds a project, no plugin system, no convention about where your files live. Each package solves one problem and composes with the others because they share vocabulary, not because they share a runtime.
They are not a compatibility promise. Versions are dates, and a later date says only that it is later — see Install and pin before you write a range into a manifest.
Where to go next
Install and pin — the versioning scheme, and the one rule it carries.
Your first handler — three packages composed into something that runs.
Every package — the whole list, filterable.