JSON

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions

.json, .jsonc, .jsonl, .jsonlog

Registry names

json

Recorded symbols

keys · nesting shape · composition

Relationship types this analyzer constructs

9 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

9 constructed, 5 not constructed. All 5 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

• Nothing in JSON calls anything, because the format has no way to express a call. What you get is shape: which key sits under which, and how deep the nesting goes. The vocabulary is contains, references, imports, uses, exports and extends — the last only for a $ref inside an allOf array, because a superset-of IS a relationship, while anyOf and oneOf are alternatives and publish only their references.
• A $ref is a string, so it is classified rather than assumed. One that names another file is recorded as both a dependency and a reference, because that is what it is; one naming a pointer inside this document resolves here; one naming neither stays unresolved and is stored at reduced confidence. Corpus-wide the ends are mostly ambiguous — 64.54% of reference endpoints match more than one symbol — so a $ref is a place to look, not a target to assume.
• Nothing is compared across documents, so name in package.json and name in a fixture are neither a conflict nor a match. And an inline array's scalar items publish nothing at all: array elements are positional and unnamed, so there is no identity to record, and only an object element inside an array becomes a symbol of its own.

Every line above was written against JSON’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .json, .jsonc, .jsonl, .jsonlog. Everything below is about where those files actually sit in a working repository.

• package.json, tsconfig.json, a lockfile and a CI fixture are all .json and all index as one family; the file's stem is the root, so package and tsconfig are two independent roots rather than two views of one.
• A JSON Schema is the case where the nesting shape is the whole point: properties, items and $defs become containers you can walk, and required marks the individual properties inside them.
• Generated JSON — a build manifest, an API response fixture, a lockfile with tens of thousands of lines — is mostly leaf values, so the records worth having are the containers and the $refs rather than the scalars. A Terraform plan JSON is the extreme case: over 10,000 symbols, nearly all of them repeating the same names.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

1. What keys does this document declare at the top level?
2. Where is this key set, and what is nested beneath it?
3. Which fields does this schema mark as required?
4. Which other files does this document reference?

What the analyzer sees in code like this

{
  "name": "acme-api",
  "scripts": { "build": "tsc" },
  "dependencies": ["express", "pg"],
  "$ref": "common.json#/definitions/Base"
}

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Web, data & config — the count beside each name is how many relationship types that family’s analyzer constructs.

• SQL10 types
• HTML14 types
• CSS8 types
• SCSS / Sass10 types
• YAML8 types
• GraphQL8 types
• HCL / Terraform10 types
• Vue14 types
• Svelte14 types
• Markdown5 types
• TOML4 types
• XML9 types
• Make8 types
• Protobuf5 types