You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pulls in the camelCase rename of every spec union and enumeration name, the new `{ kind: 'address' }` `TypeExpr` (rendered as plain `string` on the v1 TS surface), and the rc.6 revert of the rc.5 vec-of-children optional flips — leaving `programNode`, `rootNode`, `instructionNode`, `pdaNode`, and `pdaValueNode`'s child arrays required as they were in rc.4. The generator picks up the new `address` kind in both `nodeTypes` and `nodes` `typeExpr` fragments, switches the `registered*` prefix and `UNION_ALIAS_NAMES` keys to camelCase to match the new spec naming, and gains a small constructor-signature fix to avoid emitting invalid `param?: T = default` TypeScript whenever an attribute that's both optional and supplied with a default appears (no such attribute exists in v1 today, but the bug would have surfaced the moment one did). The regenerated `@codama/node-types` surface differs from rc.4 by a single docstring paragraph on `NestedTypeNode` — the spec's nested-union alias name is now camelCase. Test fixtures across the generator's suite are updated to mirror the new convention; runtime behaviour and the public TS API are unchanged.
Bump `@codama/spec` from `1.6.0-rc.4` to `1.6.0-rc.6`. The encoded surface in `@codama/node-types` is functionally unchanged; one docstring paragraph on `NestedTypeNode` now reads `nestedTypeNode<T>` instead of `NestedTypeNode<T>` to mirror the spec's new camelCase nested-union alias name.
6
+
7
+
Behind the scenes, `@codama-internal/spec-generators` learns about the new `{ kind: 'address' }``TypeExpr` (rendered as plain `string` on the v1 TS surface — a dedicated `Address` brand may follow in a future spec major), the camelCase rename of every union and enumeration name on the spec side (the generated PascalCase TS identifiers are unaffected since the generator runs each name through `pascalCase()` at render time), and a constructor-signature bug where an attribute that was both `optional` and supplied with a default would emit invalid TS (`param?: T = default`). The bug never triggered against the rc.4 v1 spec but would have surfaced once any future attribute combined `optional: true` with a configured default; the fix is to omit the `?` mark whenever an initializer is present.
0 commit comments