# @sanity/schema

Latest version **6.16.0** (published 2026-09-22) · MIT license · 0 weekly downloads

## Install

```sh
npm install @sanity/schema
pnpm add @sanity/schema
yarn add @sanity/schema
bun add @sanity/schema
```

## Health

**Score 75/100 (B)** — status: active.

Positive: has types; esm support; no vulnerabilities; has provenance; recently updated; high maintenance score; high quality score.

Warnings: low downloads.

## Facts

| | |
|---|---|
| Version | 6.16.0 |
| Published | 2026-09-22 |
| First published | 2017-01-26 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | bundled |
| Module format | ESM |
| Node | >=22.12 |
| Dependencies | 11 |
| Unpacked size | 621.4 KB |
| Known vulnerabilities | 0 |
| Install scripts | no |
| Provenance | attested (GitHub Actions) |
| GitHub stars | 6322 |
| Author | Sanity.io <hello@sanity.io> |
| Maintainers | sanity-svc.npm, sanity-io |
| Keywords | cms, content, headless, realtime, sanity, schema |

## Links

- npm: https://www.npmjs.com/package/@sanity/schema
- Repository: https://github.com/sanity-io/sanity
- Homepage: https://www.sanity.io/
- Issues: https://github.com/sanity-io/sanity/issues
- npm.io page: https://npm.io/package/@sanity/schema

## Dependencies (11)

- [leven](https://npm.io/package/leven.md) ^4.1.0
- [arrify](https://npm.io/package/arrify.md) ^3.0.0
- [dequal](https://npm.io/package/dequal.md) ^2.0.3
- [get-it](https://npm.io/package/get-it.md) ^9.5.5
- [groq-js](https://npm.io/package/groq-js.md) ^2.0.0
- [lodash-es](https://npm.io/package/lodash-es.md) ^4.18.1
- [@sanity/types](https://npm.io/package/@sanity/types.md) 6.16.0
- [humanize-list](https://npm.io/package/humanize-list.md) ^1.0.1
- [object-inspect](https://npm.io/package/object-inspect.md) ^1.13.4
- [@sanity/descriptors](https://npm.io/package/@sanity/descriptors.md) ^1.3.0
- [@sanity/generate-help-url](https://npm.io/package/@sanity/generate-help-url.md) ^4.0.0

## Alternatives

- [@opentelemetry/exporter-zipkin](https://npm.io/package/@opentelemetry/exporter-zipkin.md) — 14.8M weekly downloads
- [pusher-js](https://npm.io/package/pusher-js.md) — 2.0M weekly downloads
- [browserify](https://npm.io/package/browserify.md) — 1.7M weekly downloads
- [sqs-consumer](https://npm.io/package/sqs-consumer.md) — 1.7M weekly downloads
- [@sanity/eventsource](https://npm.io/package/@sanity/eventsource.md) — 930.8K weekly downloads

## Recent versions

- 6.16.0 (latest) — 2026-09-22
- 6.17.0-next.25 (next) — 2026-09-23
- 6.11.0 (stable) — 2026-08-25
- 4.22.1 (maintenance-v4) — 2026-08-19
- 5.31.2 (maintenance-v5) — 2026-08-19
- 6.5.0-workbench.20260714145319 (workbench) — 2026-07-14
- 6.0.0-next-major.20260611102044 (next-major) — 2026-06-11
- 5.25.0-canary.20260507124900 (canary) — 2026-05-07
- 5.14.2-alpha.15 (alpha) — 2026-03-11
- 4.20.2-fix-tsa-expression-not-allowed.2.5e90622c2d (fix-tsa-expression-not-allowed) — 2025-12-04
- 4.20.2-fix-babel-traverse-bug.2.03a7495fed (fix-babel-traverse-bug) — 2025-12-04
- 4.1.2-rita-prerelease-ref.28 (rita-prerelease-ref) — 2025-07-24
- 4.1.2-4.2.0-rita-prerelease-tag.0.28 (4.2.0-rita-prerelease-tag.0) — 2025-07-23
- 4.1.1-bump-pkg-utils.6 (bump-pkg-utils) — 2025-07-22
- 3.99.1-bitter-lemon.5 (bitter-lemon) — 2025-07-18
- … 4672 more at https://npm.io/package/@sanity/schema/versions

## README

# Sanity schema

## Terminology

- **`Schema`** A collection of types
- **`Type`** A specification of a data structure. Available through schema lookup.
- **`Member type`** A member type is a type contained by a schema type. For example, an array may specify the allowed item types by defining members types from schema types. A reference may be a reference to a set of other types. A member type is not added to the schema and is not available through schema lookup, but rather exists as a property of the owner type.

## Constraints

### No inheritance

You are almost always better off using composition, rather than inheritance hierarchies

E.g.:

```js
const PERSON = {
  type: 'object',
  name: 'person',
  fields: [
    {name: 'firstName', type: 'string'},
    {
      name: 'address',
      type: 'object',
      fields: [
        {
          name: 'street',
          type: 'string',
        },
      ],
    },
  ],
}
```

If one were to introduce a user type, it would be tempting to think of it as a subtype of person, adding a few additional fields specific for the user type, like this:

```js
const USER = {
  // modelling user as a subtype of person
  name: 'user',
  type: 'person',
  fields: [
    {
      name: 'username',
      type: 'string',
    },
  ],
}
```

A problem with the above is: how do we merge the fields? Should the fields from `PERSON` be placed before the fields from `USER`? What if both types define the same field, should the subtype override? What if that field is an object where we'd like to keep some of the fields, but remove others? It quite quickly becomes messy.

A better solution would be to define common fields outside, and re-use them across types:

e.g.:

```js
const FIRST_NAME_FIELD = {name: 'firstName', type: 'string'}
const ADDRESS_FIELD = {
  name: 'address',
  type: 'object',
  fields: [
    {
      name: 'zip',
      type: 'string',
    },
    {
      name: 'street',
      type: 'string',
    },
    {
      name: 'city',
      type: 'string',
    },
  ],
}

const PERSON = {
  type: 'object',
  name: 'person',
  fields: [FIRST_NAME_FIELD, ADDRESS_FIELD],
}

const USER = {
  type: 'object',
  name: 'person',
  fields: [FIRST_NAME_FIELD, {name: 'username', type: 'string'}, ADDRESS_FIELD],
}
```

You could even take this further by extracting the individual fields of the `address` type and compose in different ways.

---
_Source: https://npm.io/package/@sanity/schema · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._