Skip to content

[finding] the published bundle json-schema/objectstack.json declares x-schema-count: 1596 but carries 1585 definitions — and a docs page publishes that field as "the total number of definitions" #12588

Description

@huangyiirene

Origin: measured by the os-dev run for #12315 (named-$ref link branch) while surveying the emitted packages/spec/json-schema/** tree. Filed on the dev's behalf — recording only, unassigned, awaiting triage. Not fixed under #12315's claim (out of scope: that card is the reference renderer's link branch).

Measurement

At origin/main7bd6447f413d, after pnpm --filter @objectstack/spec gen:schema:

bundle x-schema-count: 1596
bundle $defs actual: 1585
delta: 11
per-schema files on disk (excl. objectstack.json): 1585

The generator's own console agrees with both halves and with the disagreement:

Generated: 1596 (124 as input shape)
✅ Generated bundled schema: objectstack.json (1585 definitions)
✅ Successfully generated 1596 schemas.

Mechanism

packages/spec/scripts/build-schemas.ts increments count once per emitted schema, but records each one into generatedSchemas keyed by `${categorySlug}/${schemaName}` (~line 427), and the bundle's $defs is assembled from that map (~line 2546):

'x-schema-count': count,// 1596 — one per emit
...
for(const[defKey,schema]ofgeneratedSchemas)defs[defKey]=schema;// 1585 — one per KEY

So 11 emits share a def key with an earlier emit and are overwritten. The disk count (1585 files) matches $defs, not count — the same overwrite happens at the file level. findDefKeyCollisions does not stop these; per the in-source note, a self-alias is exempt from that gate (lib/def-key-collisions.ts), which is the most likely population here.

Why it's worth a card

  1. The field is wrong in a published artifact.json-schema/** ships in the tarball — 1586 of 1859 files in npm pack --dry-run — so the overstatement is on the consumer's disk, not just in a build log.
  2. A published docs page states the false reading.content/docs/deployment/troubleshooting.mdx:438 — "its x-schema-count field reports the total number of definitions". It does not; it reports emit attempts, and is high by 11.
  3. It masks the exempt-collision population. The delta is currently the only externally visible signal that 11 emits are being silently overwritten. Whether those overwrites are all benign self-aliases is itself unverified here — the count discrepancy is the symptom, and the resolution should establish which it is.

Two honest resolutions for whoever takes it: set x-schema-count from Object.keys(defs).length so the artifact describes itself (and decide separately whether 11 overwritten emits deserve their own report line), or keep the emit count and rename/redocument the field. The first looks right — a self-describing artifact should count what it contains — but the overwrite population should be identified either way rather than left implied.

Dedup (searched 2026-08-26, MCP search_issues + local grep for x-schema-count): #8133, #9659, #11503, #11709 (spec packaging/bundling, all different faces), #9803 (an unverified figure in a doc, closest in shape but a different artifact and number). No open card covers this field.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions