Filed unassigned from the implementation of #5160. Not fixed there — that card is scoped to the TS2305 "imports a name the module does not export" class; this is TS2351, a different diagnostic on a name that is exported.
What was measured
Against the built packages/core/dist/index.d.ts with the #5138 snippet gate:
packages/core/README.md:49:22 TS2351: This expression is not constructable. Type 'Registry< any >' has no construct signatures.
The README's Component Registry example:
import{ComponentRegistry}from'@object-ui/core'constregistry=newComponentRegistry()registry.register('button',buttonMetadata)constmetadata=registry.get('button')packages/core/dist/registry/Registry.d.ts declares:
exportdeclareconstComponentRegistry: Registry<any>;
It is a process-level singleton instance the whole app shares — SchemaRenderer resolves every type against that one object — not a constructor. new ComponentRegistry() does not compile, and if it somehow did it would produce a second, empty registry that nothing renders from, which is the more expensive half of the mistake.
Registry itself is exported and is a real class, so a reader who wants their own isolated registry writes new Registry(). The README's two following lines (register / get) are correct as written against the singleton.
Suggested fix
Drop the new:
import{ComponentRegistry}from'@object-ui/core'ComponentRegistry.register('button',buttonMetadata)constmetadata=ComponentRegistry.get('button')...and say in one line that it is the shared singleton, since that is the part a reader cannot infer from the example. packages/components/README.md was given exactly that wording in #5160 and can be copied.
Why it is worth a card
packages/core/README.md ships to npm inside the package's files. Same class of harm as #5160: a reader who copies the snippet gets a compile error rather than a degraded render. It stayed green under every gate until #5138 because check-doc-component-types reads type literals and check-doc-links reads links — neither reads a constructor call.
This is one of the two diagnostics left on packages/core/README.md's UNGATED_DOCS entry after #5160 (plus TS2339x2 TS2351x1); the TS2339 pair is #5257.
Related
Filed unassigned from the implementation of #5160. Not fixed there — that card is scoped to the TS2305 "imports a name the module does not export" class; this is TS2351, a different diagnostic on a name that is exported.
What was measured
Against the built
packages/core/dist/index.d.tswith the #5138 snippet gate:The README's Component Registry example:
packages/core/dist/registry/Registry.d.tsdeclares:It is a process-level singleton instance the whole app shares —
SchemaRendererresolves everytypeagainst that one object — not a constructor.new ComponentRegistry()does not compile, and if it somehow did it would produce a second, empty registry that nothing renders from, which is the more expensive half of the mistake.Registryitself is exported and is a real class, so a reader who wants their own isolated registry writesnew Registry(). The README's two following lines (register/get) are correct as written against the singleton.Suggested fix
Drop the
new:...and say in one line that it is the shared singleton, since that is the part a reader cannot infer from the example.
packages/components/README.mdwas given exactly that wording in #5160 and can be copied.Why it is worth a card
packages/core/README.mdships to npm inside the package'sfiles. Same class of harm as #5160: a reader who copies the snippet gets a compile error rather than a degraded render. It stayed green under every gate until #5138 becausecheck-doc-component-typesreadstypeliterals andcheck-doc-linksreads links — neither reads a constructor call.This is one of the two diagnostics left on
packages/core/README.md'sUNGATED_DOCSentry after #5160 (plus TS2339x2 TS2351x1); the TS2339 pair is #5257.Related