Codama ➤ Renderers ➤ JavaScript

This package generates JavaScript clients from your Codama IDLs. The generated clients are compatible with @solana/kit.

Installation

pnpm install @codama/renderers-js

Usage

Add the following script to your Codama configuration file.

{
    "scripts": {
        "js": {
            "from": "@codama/renderers-js",
            "args": ["clients/js"]
        }
    }
}

The first argument is the package folder — i.e. where the package.json lives. The generated files will be written to src/generated within that folder by default.

The generated client contains typed helpers for the accounts, instructions, PDAs, defined types, errors, events and program of each program in the Codama tree. For instance, program events are each rendered into a dedicated events/ page exposing their discriminator constants, payload type, codec functions and a parseMyEvent helper, whilst the program page offers an identifyMyProgramEvent function to recognise raw event data.

An object can be passed as a second argument to further configure the renderer. See the Options section below for more details.

Options

The renderVisitor accepts the following options.

Name	Type	Default	Description
deleteFolderBeforeRendering	boolean	true	Whether the base directory should be cleaned before generating new files.
formatCode	boolean	true	Whether we should use Prettier to format the generated code.
generatedFolder	string	'src/generated'	The path to the generated folder relative to the package folder.
prettierOptions	PrettierOptions	{}	The options to use when formatting the code using Prettier.
asyncResolvers	string[]	[]	The exhaustive list of ResolverValueNode's names whose implementation is asynchronous in JavaScript.
customAccountData	string[]	[]	The names of all AccountNodes whose data should be manually written in JavaScript.
customInstructionData	string[]	[]	The names of all InstructionNodes whose data should be manually written in JavaScript.
linkOverrides	Record<'accounts' | 'definedTypes' | 'instructions' | 'pdas' | 'programs' | 'resolvers', Record<string, string>>	{}	A object that overrides the import path of link nodes. For instance, { definedTypes: { counter: 'hooked' } } uses the hooked folder to import any link node referring to the counter type.
dependencyMap	Record<string, string>	{}	A mapping between import aliases and their actual package name or path in JavaScript.
dependencyVersions	Record<string, string>	{}	A mapping between external package names — e.g. @solana/kit — and the version range we should use for them — e.g. ^6.0.0. The renderer offers default values for all external dependencies it relies on but this option may be used to override some of these values or add new ones.
internalNodes	string[]	[]	The names of all nodes that should be generated but not exported by the index.ts files.
nameTransformers	Partial<NameTransformers>	{}	An object that enables us to override the names of any generated type, constant or function.
nonScalarEnums	string[]	[]	The names of enum variants with no data that should be treated as a data union instead of a native enum type. This is only useful if you are referencing an enum value in your Codama IDL.
renderParentInstructions	boolean	false	When using nested instructions, whether the parent instructions should also be rendered. When set to false (default), only the instruction leaves are being rendered.
kitImportStrategy	'granular' | 'preferRoot' | 'rootOnly'	'preferRoot'	Whether to generate imports from granular packages (e.g. @solana/addresses, @solana/codecs-strings) or from the @solana/kit package. 'granular': always use granular packages when available. 'preferRoot' (default): use @solana/kit when the symbol is exported from it; otherwise fall back to granular packages. 'rootOnly': only import from the @solana/kit package. This may use @solana/kit subpath exports (e.g. @solana/kit/program-client-core). This is useful when installing @solana/kit as a peerDependency, but may require TypeScript moduleResolution: "bundler".
erasableSyntax	boolean	false	Whether to avoid TypeScript syntax that cannot be erased by a type-stripping compiler. When enabled, generated enum declarations are replaced with const objects paired with union types of the same name, so the generated client compiles under TypeScript's erasableSyntaxOnly option and runs under Node.js type stripping. The const objects preserve both forward and reverse enum lookups at runtime and in TypeScript.
importExtension	'js' | 'ts'	undefined	When set, the relative import and re-export specifiers of the generated code include an explicit file extension — generated files become ./myAccount.js and generated directories become ./accounts/index.js. Use 'js' for Node ESM resolution — i.e. TypeScript's moduleResolution: "nodenext" — and 'ts' for runtimes that execute TypeScript directly, such as Deno or Node type stripping, which with TypeScript requires allowImportingTsExtensions and, when also compiling to JavaScript, rewriteRelativeImportExtensions. Only renderer-generated code paths are rewritten. Paths provided via dependencyMap or linkOverrides are treated as complete module specifiers and emitted verbatim, including relative paths without extensions. This keeps caller-owned mappings unchanged while renderer-owned file and directory paths receive the configured extension.
syncPackageJson	boolean	true	Whether to update the dependencies of the existing package.json — or create a new package.json when missing — inside the package folder.