# The Standard Schema spec is delivered by copy-paste, and the visible block is a base type

> standard-schema is a set of TypeScript interfaces that standardise how validation libraries expose themselves to tools. Libraries are told to paste the interface into their own codebase rather than depend on a package, the one specification visible in the README is a base type that other specs extend, and the root manifest configures three tools while defining no lint, format or test script.

**standard-schema/standard-schema** — A standard interface for TypeScript schema validation libraries

- Repository: https://github.com/standard-schema/standard-schema
- Website: https://standardschema.dev
- Stars: 3,650 · Forks: 123
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/standard-schema-standard-schema

## The specification is delivered by copy-paste

The instructions are unusually direct. The specifications can be found in the README in their entirety, and a library wishing to implement one is told to copy the code block into its own codebase. The same interface is also published as a package on two registries, the npm registry and the JavaScript registry. That double delivery is the design, not an accident: the stated goal is to let tools accept a single input containing the types and capabilities they need, with no library-specific adapters and no extra dependencies, and pasting an interface is the only way to guarantee there is no dependency. The cost is that every implementation carries its own copy, so the specification's version is something you have to track rather than something your package manager resolves.

## The block in the README is a base type, not a validator

The one specification visible in the file is headed Standard Typed, and its own documentation comment describes it as a base type extended by other specs. What follows is an interface with a single property whose key is the standard's name wrapped in a tilde character:

```ts
// #########################
// ###   Standard Typed  ###
// #########################

/** The Standard Typed interface. This is a base type extended by other specs. */
export interface StandardTypedV1<Input = unknown, Output = Input> {
  /** The Standard properties. */
  readonly "~standard": StandardTypedV1.Props<Input, Output>;
}
```

The tilde is the interesting part of the naming. A property key nobody would choose for a real field cannot collide with one, which is what makes feature detection safe. The block then opens a declared namespace holding a properties interface, and the second of its fields is cut off partway through its comment, after the words about the vendor name. So the visible specification is a foundation rather than the interface most people are looking for.

## The version is part of the type, not a runtime flag

Inside that namespace, the first documented field is the version number of the standard, declared as the literal type one rather than as a number. That single choice does a lot of work. Because the version is part of the type, an implementation declaring a different version does not satisfy a consumer typed against version one, and the mismatch surfaces when your code is compiled rather than when a tool runs. It also means the version travels with the interface, so a consumer can branch on it in the type system. The releases follow the same logic: a one point zero, a release candidate that predates it by seventeen days, and a one point one the following December, while the interface in the README still declares one.

## The root package is private and publishes nothing

The manifest at the repository root is a workspace root, not a package anyone installs. It is marked private, its version is zero point zero point zero, and its description matches the README's subtitle rather than naming an artefact. What actually reaches a registry is named in the scripts: the build command filters two packages by name, one for the specification and one for utilities, which are the two things the README says are published. So the version you depend on is the version of a package inside the packages directory, and the root's own version is a placeholder that has never been incremented. The author field names one person, and the repository field points at the same GitHub URL as the project site links to.

## Three tools are configured and no script runs any of them

The root manifest lists a formatter, a second formatter and a compiler as development dependencies, and the repository root carries a configuration file for one of them. What the scripts section does not contain is any command that uses them. There are exactly two scripts, one that builds the two packages and one that runs the website, and neither runs the linter, the formatter or a type check, and there is no test script and no test configuration at the root. That combination is normal for a repository whose deliverable is an interface definition rather than an application: there is nothing to assert, so the tools are there for contributors. It does mean the checks live wherever each package defines them, and this file is not where to look for them.

## The build deliberately skips the website

Two scripts, two different sets of workspaces. The build filters the specification package and the utilities package, and that is the whole build. The other script filters a third workspace whose name ends in nextjs and runs its development command, which is the documentation site. So the repository holds at least three workspaces: the specification, a utilities package, and a Next.js application that is never built by the build script. That split is the practical shape of the project, since the spec is a type definition, the utilities exist so consumers do not reimplement common helpers, and the site is the place the rest of the documentation lives, which is why the README itself can be short enough to consist of an introduction and one code block.

## The newest release is nine months older than the last commit

The release history is three entries. A release candidate named for the one point zero spec, published in the middle of January, with a title that names the package rather than the repository version. The final one point zero, seventeen days later. And one point one the following December. After that, nothing, while the default branch's last push is dated 2026-09-30. So the published version and the branch have been apart for most of a year, which for a specification whose entire value is that tools and libraries agree on a shape is the number to keep an eye on. Nothing in the file reports which specification version the branch currently describes, so the tags and the branch have to be compared by hand.

## Conclusion

Standard Schema earns a place if you maintain a validation library and want tools to consume it without a bespoke adapter, since the whole proposal is a single property on an object that any tool can feature-detect. Two things to know before you adopt it. Delivery is by copy-paste, so you own the code and the compatibility questions that come with owning it, and the version is baked into the interface type, which makes a mismatch a compile error rather than a runtime surprise. And the specification is still moving: the newest release is from December 2025 while the branch has been worked since, and the only prose in the README is the introduction and one interface block, with everything else on the project site.

## FAQ

### What is Standard Schema?

It is a set of TypeScript interfaces that standardise how shared functionality is provided and consumed in the ecosystem, so that tools can accept one input carrying the types and capabilities they need without library-specific adapters or extra dependencies. The README describes the goal as an ecosystem that is fair for implementers, friendly for consumers and open for end users.

### How do I implement Standard Schema in my validation library?

The README says to copy the specification code block into your codebase, and also publishes the same interface as a package on npm and on the JavaScript registry. The visible interface is called Standard Typed and its own comment describes it as a base type that other specifications extend, with a single property keyed by the standard's name wrapped in a tilde so it cannot collide with a real field.

### How does Standard Schema handle versioning?

The version is declared as the literal type one inside the specification's properties interface, so it is part of the type rather than a runtime flag, and an implementation declaring a different version does not satisfy a consumer typed against version one. The releases are a one point zero, a release candidate before it, and a one point one the following December.

### Does the standard-schema repository publish its own package?

Not from the root. The root manifest is marked private with a placeholder version of zero point zero point zero and defines only two scripts. The build script filters two workspaces by name, the specification package and a utilities package, and those are what the README says are available on npm and on the JavaScript registry. A third workspace, a Next.js site, is run by the other script and is not part of the build.

### Does the standard-schema repository have tests?

Nothing in the root manifest suggests any. There is no test script and no test configuration at the root, and the two scripts that exist build the specification and utilities workspaces and run the website. The root does configure a linter, a formatter and a compiler as development dependencies, but no script at that level invokes them.

## Sources

- [License: MIT](https://github.com/standard-schema/standard-schema/blob/main/LICENSE)
- [Project website](https://standardschema.dev)
- [README](https://github.com/standard-schema/standard-schema/blob/main/README.md)
- [Releases](https://github.com/standard-schema/standard-schema/releases)
- [standard-schema/standard-schema on GitHub](https://github.com/standard-schema/standard-schema)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/standard-schema-standard-schema