BuildRegistryOptions
Interface in Tooling
Options for buildRegistry.
import type { BuildRegistryOptions } from 'typeshade'
The signature, the description and the examples come from the compiler's own source at commit 26de7be8.
Syntax
interface BuildRegistryOptions { readonly order?: readonly string[]; readonly typeName?: string; readonly recordName?: string; readonly valueType?: string; readonly imports?: readonly string[]; readonly regenerateWith?: string; readonly stamp?: string;}Instance properties
orderoptionalread onlyreadonly string[]The curated id order. When given, it must name every discovered id and no others: a new module nobody registered, or a registered id whose module was deleted, both make
buildRegistrythrow. Omit to use discovery order.typeNameoptionalread onlystringName of the generated union type. Default
RegistryKey.recordNameoptionalread onlystringName of the generated id → module record. Default
REGISTRY.valueTypeoptionalread onlystringType annotation for a registry value, e.g.
ShaderExample. Defaultunknown.importsoptionalread onlyreadonly string[]Extra import line(s) placed above the generated ones, where
valueTypecomes from.regenerateWithoptionalread onlystringThe command that regenerates this file. It is named in the generated file’s banner and in the error message when
orderand the discovered set disagree, so a reader who hits that failure knows what to run.stampoptionalread onlystringThe emit identity the registry’s shader artifacts were produced with; pass the string returned by
emitIdentity. It is recorded in the generated file’s banner, so a committed registry says which emit configuration wrote it. When two builds produce different output from the same modules, the first line of the diff then names the difference.
See also
Source
src/core/registry.ts, line 38, at commit 26de7be8