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
{{ message }}
Repository navigation
Commit e9dfcfa
Browse filesBrowse the repository at this point in the historyBrowse files
Regenerate the node types, constructors and core visitors from the Codama v2 spec (`@codama/spec@2`).
8
+
9
+
The node model changes substantially from v1:
10
+
11
+
-**`name` → `identifier`.** Every named node (`programNode`, `accountNode`, `instructionNode`, links, …) now carries `identifier` instead of `name`, and identifiers preserve their casing — v2 no longer mandates camelCase (`transfer_tokens` and `transferTokens` are both valid; uniqueness is resolved by case-folding).
12
+
-**Numeric system rework.**`numberTypeNode`/`numberValueNode` split into `integerTypeNode`/`floatTypeNode` and `integerValueNode`/`floatValueNode` (numeric values are string-encoded to stay lossless through JSON). `amountTypeNode`/`solAmountTypeNode` become `fixedPointTypeNode`; new `durationTypeNode`; `dateTimeTypeNode`/`durationTypeNode` carry `ticksPerSecond`.
13
+
-**Flat transforms.** The wrapper type nodes (`fixedSizeTypeNode`, `sizePrefixTypeNode`, `pre/postOffsetTypeNode`, `sentinelTypeNode`, `hiddenPrefix/SuffixTypeNode`) are removed; every type node instead carries an optional `transforms: transformNode[]` applied innermost-first.
14
+
-**Instruction data.**`instructionArgumentNode`, `instructionArgumentLinkNode`, `resolverValueNode` and `instructionNode.arguments`/`extraArguments` are removed; instruction arguments live in `instructionNode.data`, reached via path expressions. `argumentValueNode` → `dataValueNode`; `accountFieldValueNode` → `accountDataValueNode`.
15
+
-**Enum variants unified.** The three variant nodes collapse into a single `enumVariantTypeNode` with an optional `data`.
16
+
-**Text and docs.**`docs` and text-bearing attributes are the union `string | textNode`; a `textNode` carries structured metadata (plugins). New `textNode`.
17
+
-**Universal plugins.** Every node gains an optional `plugins: pluginNode[]` base attribute — the extension point for renderer-specific or not-yet-standardised metadata.
18
+
-**Other.**`programNode.origin` removed (provenance moves to plugins); `pluginNode.name` → `pluginNode.namespace`; `sentinelCountNode` added; path expressions for field references and discriminators.
19
+
20
+
Node factory ergonomics: trailing optional parameters now live in the constructor's `options` bag (e.g. `constantNode(identifier, type, value, { docs })`, `accountLinkNode(identifier, { program })`).
Parts of the codebase — everything under a `generated/` directory — are produced by the private `@codama-internal/spec-generators` package from the [`@codama/spec`](https://github.com/codama-idl/spec) meta-model, and must never be edited by hand. CI regenerates everything and fails on any diff, so committed generated code always matches the spec pins in `packages/spec-generators/package.json`:
16
+
Most `generated/` directories — those under `@codama/node-types`, `@codama/nodes` and `@codama/visitors-core`— are produced by the private `@codama-internal/spec-generators` package from the [`@codama/spec`](https://github.com/codama-idl/spec) meta-model, and must never be edited by hand. CI regenerates them and fails on any diff, so committed generated code always matches the single living spec pin in `packages/spec-generators/package.json`:
17
17
18
-
-`@codama/spec` is the living pin: the spec version the current major is generated from.
19
-
-`@codama/spec-v1` is an aliased pin to the final release of an older major, used solely to refresh the frozen node types committed in `@codama/upgrade`.
18
+
-`@codama/spec` is the living pin: the spec version the current major is generated from. It is exact rather than a range, so generated output only changes through a deliberate, reviewable pin (or generator) change.
20
19
21
-
Both pins are exact rather than ranges, so generated output only changes through a deliberate, reviewable pin (or generator) change.
20
+
The generator is **single-major**: it only renders the spec on its own branch. Node types for **older** majors live as frozen static snapshots under `packages/upgrade/src/vN/generated` (e.g. `src/v1/generated`); these are hand-maintained source, are **not** regenerated by `pnpm generate`, and are excluded from the CI freshness check. See `packages/upgrade/src/v1/README.md`.
22
21
23
22
## Changesets
24
23
@@ -28,11 +27,11 @@ Any user-facing change needs a changeset: run `npx changeset add --empty` and ed
28
27
29
28
Branch, dist-tag and lifecycle mechanics (cut / bake / promote) are defined once for the whole ecosystem in the spec repository's [RELEASING.md](https://github.com/codama-idl/spec/blob/HEAD/RELEASING.md). Releasing major N+1 of the [Codama spec](https://github.com/codama-idl/spec) additionally requires the following steps specific to this repository. The design intent is that this list never grows: one new upgrade function per major, everything else mechanical.
30
29
31
-
1.**Freeze the vN node types.**In `packages/spec-generators/package.json`, repoint the frozen alias at the final N.x spec release (renaming it `@codama/spec-vN`) and move the living `@codama/spec` pin to the (N+1).x release. Running `pnpm generate` then commits the frozen vN snapshot under `packages/upgrade/src/vN/` and restamps `CODAMA_VERSION` — remember to also freeze copies of the hand-written siblings (`brands.ts`, `Docs.ts`, `Version.ts`) next to the generated output, as done for v1.
32
-
2.**Write the upgrade step.** Add a single hand-written, pure `upgradeVNToVN+1` function to `@codama/upgrade` — a JSON-tree-in, JSON-tree-out converter in the `nodes-from-anchor` top-down style — and wire it into `upgrade()` as its `if (major <= N)` block. Export the vN types as a type-only namespace (`export type * as vN`) from the package index.
33
-
3.**Run the ecosystem lifecycle.** Cut this repository's `N.x` maintenance branch per RELEASING.md, after which `main` hosts the vN+1 work, with one codama-specific detail: the seeded major changeset covers **all** public packages, upholding the same-major invariant. `main` then versions as `(N+1).0.0-rc.n` under the `rc` dist-tag, bakes under `next`, and is promoted to `latest` while `N.x` switches to `release-N.x`. Old majors receive clarifications and documentation fixes only, never semantic changes.
30
+
1.**Freeze the vN node types.**Before moving the living `@codama/spec` pin to the (N+1).x release, snapshot the current vN node types into `@codama/upgrade`: copy `@codama/node-types/src/generated` into `packages/upgrade/src/vN/generated`, keeping the layout identical so a later backported vN change can be ported forward by applying the same patch. Also copy the hand-written siblings (`brands.ts`, `Docs.ts`, `Version.ts`) next to it as vN-shaped frozen copies, so the snapshot is self-contained, and export the vN types as a type-only namespace (`export type * as vN`) from the package index. The snapshot is static source — it is never regenerated. Then move the living `@codama/spec` pin to the (N+1).x release and run `pnpm generate`, which rewrites the living `generated/` dirs and restamps `CODAMA_VERSION`.
31
+
2.**Write the upgrade step.** Add a single hand-written, pure `upgradeVNToVN+1` function to `@codama/upgrade` — a JSON-tree-in, JSON-tree-out converter in the `nodes-from-anchor` top-down style — and wire it into `upgrade()` as its `if (major <= N)` block.
32
+
3.**Run the ecosystem lifecycle.** Cut this repository's `N.x` maintenance branch per RELEASING.md, after which `main` hosts the vN+1 work, with one codama-specific detail: the seeded major changeset covers **all** public packages, upholding the same-major invariant. `main` then versions as `(N+1).0.0-rc.n` under the `rc` dist-tag through the candidacy, and is promoted to `latest` while `N.x` switches to `release-N.x`. Old majors receive clarifications and documentation fixes only, never semantic changes.
34
33
35
34
Two invariants protect consumers and must never be broken:
36
35
37
36
-**The upgrade chain is append-only.** The upgrade functions and frozen node types in `@codama/upgrade` are committed source with zero runtime dependencies; they are never removed or rewritten, so every major back to 1.0.0 stays upgradable forever.
38
-
-**Frozen types refresh lazily, generators are never forked.** The generators on `main` only ever consume two spec eras: the living pin and the frozen alias. Keep the alias until the meta-model API drifts incompatibly and `spec-generators` stops compiling — a loud tripwire whose response is to delete the freeze block and the alias (two lines), never to fork era-specific generators. If a backported old-major spec patch matters after that point, generate once on the era's maintenance branch and copy the output forward; otherwise, slightly stale docblocks in frozen types are acceptable, since old majors never change shape.
37
+
-**The generator is single-major; snapshots are static.** The generator on `main` only ever renders the living spec of the current major — it is never forked or taught to speak an older spec dialect. Older majors' node types are frozen static snapshots under `packages/upgrade/src/vN/generated`, whose layout mirrors that major's `@codama/node-types/src/generated` so a rare backported change is ported forward as a patch. Slightly stale docblocks in a snapshot are acceptable, since old majors never change shape.
/** The size of the account in bytes, when the data length is fixed. */
24
26
readonlysize?: number;
25
-
/** Markdown documentation for the account. */
26
-
readonlydocs?: Docs;
27
27
28
28
// Children.
29
+
/** Markdown documentation for the account. */
30
+
readonlydocs?: TDocs;
29
31
/**
30
-
* The struct describing the account data.
31
-
* It must be a struct so its fields can be referenced by other nodes — e.g. `accountFieldValueNode`.
32
+
* The type describing the account data — any type node, including a `definedTypeLinkNode` to share or reuse a defined type.
33
+
* Nodes that reference account fields by name — e.g. `accountDataValueNode` or `fieldDiscriminatorNode` — are only valid when this type resolves to a struct (following links).
32
34
*/
33
35
readonlydata: TData;
34
36
/** A link to the PDA the account is derived from, if applicable. */
@@ -38,4 +40,9 @@ export interface AccountNode<
38
40
* When multiple are listed, they are combined with a logical AND.
39
41
*/
40
42
readonlydiscriminators?: TDiscriminators;
43
+
/**
44
+
* Namespaced plugins with custom structured data.
45
+
* The universal extension point for renderer-specific or not-yet-standardised metadata.
0 commit comments