@codama/nodes-from-anchor@1.5.1
Patch Changes
-
#995
2f7c443Thanks @lorisleiva! - Regenerate the entire@codama/node-typessource surface from the encoded@codama/specdescription, via the new private@codama-internal/spec-generatorspackage.The bulk of the surface lives under
src/generated/and is produced by thegen-ts-node-typesgenerator from the spec. The previously hand-maintained interfaces are gone; every node, union, enumeration, and per-spec shared type is rebuilt from the spec on everypnpm generaterun.A small set of static helpers — the brand types, the
Docsalias, and theVersiontemplate-literal type — live as hand-written sibling files at the top ofpackages/node-types/src/, alongside the existingProgramVersiondeprecated alias. They are imported by the generated surface but never regenerated, since their content doesn't depend on the spec. The generator wipes onlysrc/generated/on every run; hand-written content at the top level survives. The per-specCodamaVersionliteral stays generated, in its ownsrc/generated/shared/codamaVersion.tsfile pinned to the spec version at generation time.Most of the rebuild is structural: imports now point at per-file paths (
./linkNodes/PdaLinkNode) instead of subdirectory barrels, every interface and field carries a JSDoc block sourced from the spec, and array fields are emitted asArray<T>rather thanT[]so an inline-union element type doesn't need extra parentheses to preserve precedence. A handful of named API differences also shake out from this:accountNode.sizeis now typed asnumber | undefined(the previous| nullarm had no consumer and is dropped).programNode.originis now typed as the namedProgramOriginunion ('anchor' | 'shank') instead of an inline literal union.instructionAccountNode.isSignerandinstructionRemainingAccountsNode.isSignernow readboolean | 'either'instead oftrue | false | 'either'(a TypeScript-only readability normalisation; the encoded spec keeps the explicittrue | falseform so other codegen targets can still emit a multi-variant enum).numberTypeNode.formatandstringTypeNode.encodingare emitted as namedNumberFormat/BytesEncodingaliases imported from./shared/, with the same generic-narrowing behaviour preserved.programNode.versionis now typed as the unifiedVersiontemplate-literal alias (`${number}.${number}.${number}`) — a tighter shape than the previous plain string, so non-conforming literal strings will now surface as TypeScript errors at the call site. The historicalProgramVersionname is preserved as a hand-written@deprecatedre-export so existing consumers continue to compile;@codama/nodes-from-anchoris updated to importVersiondirectly.docs?fields use aDocs = Array<string>alias mirroring the'docs'TypeExprkind in@codama/spec. The alias is hand-written and lives atpackages/node-types/src/Docs.ts.- Documentation strings that ship as multiple paragraphs in the spec now render as multi-paragraph JSDoc blocks. Affected fields and types include
accountNode.discriminators,instructionNode.discriminators,instructionAccountNode.isSigner,instructionRemainingAccountsNode.isSigner,rootNode, theConditionalValueNodeinterface and itscondition,InstructionInputValueNode,ResolverValueNode,AmountTypeNodeand itsunit,MapTypeNode.size,NestedTypeNode,StringTypeNode.size,EnumValueNode.value, andNumberValueNode.number.
Alongside the per-node interfaces, the package now exports seven
Registered<Category>Nodecategory-registry unions (RegisteredContextualValueNode,RegisteredCountNode,RegisteredDiscriminatorNode,RegisteredLinkNode,RegisteredPdaSeedNode,RegisteredTypeNode,RegisteredValueNode) corresponding one-to-one with@codama/spec's category registries, plus aGetNodeFromKind<TKind extends NodeKind>helper that resolves to the concrete interface for a given kind. The registry unions are the recommended extension point for downstream packages that need to introduce custom node kinds.The generator consumes
@codama/spec@1.6.0-rc.4, which reshapes the spec into per-category groups (spec.categories[]) and renames thenestedTypeNodeTypeExprkind tonestedUnion(with an explicitaliasfield). Alldocs?fields throughout the spec are arrays of paragraph strings rather than single newline-separated strings — the renderer accepts the array shape directly. Internally, the generator's renderers are layout-agnostic: they emituse(...)calls keyed by symbolic module strings (e.g.'node:numberTypeNode','enumeration:Endianness','brand:CamelCaseString'), and a single per-specRenderScoperesolves those symbolic keys to concrete file locations at write time. Adding a new file kind to the generator means extending theRenderScopesymbol map; renderers themselves stay free of file-layout knowledge. -
Updated dependencies [
0b3a781]:- @codama/nodes@1.8.0
- @codama/errors@1.8.0
- @codama/visitors@1.8.0