Files
pezkuwi-api/packages/metadata-builders
SatoshiQaziMuhammed e3c72817fb chore(papi): commit the sources behind the four polkadot-api packages (#15)
* chore(papi): commit the sources behind the four polkadot-api packages

papi-utils, bizinikiwi-bindings, metadata-builders and merkleize-metadata
held only dist/ builds, and no repository held their source. Every
source map in dist/ embeds the TypeScript it was compiled from; that is
now committed as src/ (59 files), and it matches upstream polkadot-api
(MIT) exactly once @polkadot-api/* imports are renamed:

  papi-utils           @polkadot-api/utils 0.2.0
  bizinikiwi-bindings  @polkadot-api/substrate-bindings 0.16.6
  metadata-builders    @polkadot-api/metadata-builders 0.13.0-0.13.2
  merkleize-metadata   @polkadot-api/merkleize-metadata 1.1.21-1.1.23

scripts/check-papi-sources.mjs, run in the lint job, fails unless the
source embedded in dist/ is exactly the committed src/. tsconfig.json
excludes these src/ trees; ESLint already skipped the packages. Each
README now states the upstream package and version.

* chore(papi): keep the upstream sources in upstream-src/

The pezkuwi-dev build treats any package with a src/ directory as its
own: it requires our license header on every file and builds it. These
are upstream files that must stay byte-identical to the source embedded
in dist/, so they live in upstream-src/ instead, which neither the build
nor the root tsconfig picks up.
2026-10-19 22:50:59 +04:00
..
2026-01-22 15:40:12 +03:00
2026-01-22 15:40:12 +03:00

@pezkuwi/metadata-builders

Source: upstream-src/ is @polkadot-api/metadata-builders 0.13.2 from polkadot-api (MIT), with imports of @polkadot-api/* renamed to @pezkuwi/* (substrate-bindings → bizinikiwi-bindings). dist/ is its build; scripts/check-papi-sources.mjs fails CI unless the source embedded in dist/ equals upstream-src/.

The upstream README follows.


@polkadot-api/metadata-builders

This package has multiple functions that read a metadata object, denormalizes it, and builds other structures needed for different processes

## getLookupFn

interface MetadataLookup {
  (id: number): LookupEntry
  metadata: V14 | V15
}

function getLookupFn(metadata: Metadata): MetadataLookup

Given the a metadata, returns a function that will give the LookupEntry for an id along. The function also has access to the original metadata, as it's usually needed to work with the actual lookup.

The LookupEntry is a denormalized data structure for one entry in the metadata. It also "shortcuts" type references when those are pointers (composites or tuples of length 1). Essentially, it's a union of each of the different types that can be found in the lookup, mostly equivalent to something like:

type TerminalVar =
  | PrimitiveVar // u8, str, char, i128, etc.
  | CompactVar
  | BitSequenceVar
  | AccountId32

type ComposedVar =
  | TupleVar
  | StructVar
  | SequenceVar
  | ArrayVar
  | OptionVar
  | ResultVar
  | EnumVar

type LookupEntry = TerminalVar | ComposedVar

Where, for instance, a StructVar is of the shape

type StructVar = {
  type: "struct"
  value: Record<string, LookupEntry>
}

It's useful to get types referenced by storage calls, etc.

getDynamicBuilder

function getDynamicBuilder(metadataLookup: MetadataLookup): {
  buildDefinition: (id: number) => Codec
  buildConstant: (pallet: string, name: string) => Codec
  buildEvent: (pallet: string, name: string) => VariantEntry
  buildError: (pallet: string, name: string) => VariantEntry
  buildCall: (pallet: string, name: string) => VariantEntry
  buildStorage: (pallet: string, entry: string) => StorageEntry
  buildRuntimeCall: (api: string, method: string) => RuntimeEntry
}

Generates all the codecs needed to SCALE encode or decode the data for any interaction with the chain.

buildDefinition returns the codec for the type identified by the parameter id

buildConstant returns the codec for the requested constant (equivalent as calling buildDefinition with the type id of that constant)

buildEvent, buildError and buildCall return an object with the codec, and the indices of the pallet and entry within the metadata:

interface VariantEntry {
  location: [number, number] // [palletIdx, entryIdx],
  codec: Codec
}

buildStorage creates all the encoders/decoders needed to encode a storage call and decode its result:

interface StorageEntry {
  // Encodes the arguments of the storage call.
  enc: (...args: any[]) => string
  // Decodes the result from the storage call.
  dec: (value: string) => any
  // Decodes the arguments of the storage call
  keyDecoder: (value: string) => any[]
  // Expected number of arguments
  len: number
  // Decoded fallback value as defined in the metadata entry
  fallback: unknown
}

Similarly, buildRuntimeCall returns the codecs for both encoding the arguments of the runtime call, and the codec for decoding the result

interface RuntimeEntry {
  args: Codec<any[]>
  value: Codec<any>
}

getChecksumBuilder

function getChecksumBuilder(metadataLookup: MetadataLookup): {
  buildDefinition: (id: number) => string | null
  buildRuntimeCall: (api: string, method: string) => string | null
  buildStorage: (pallet: string, entry: string) => string | null
  buildCall: (pallet: string, name: string) => string | null
  buildEvent: (pallet: string, name: string) => string | null
  buildError: (pallet: string, name: string) => string | null
  buildConstant: (pallet: string, constantName: string) => string | null
}

Generates the checksums for the different components defined in the metadata.

buildDefinition builds the checksum of one of the types in the lookup. The rest of the methods build the checksum for each of the interfaces of the chain.