@codama/renderers-js
Version:
JavaScript renderer compatible with the Solana Kit library
63 lines (48 loc) • 22.5 kB
Markdown
# Codama ➤ Renderers ➤ JavaScript
[![npm][npm-image]][npm-url]
[![npm-downloads][npm-downloads-image]][npm-url]
[npm-downloads-image]: https://img.shields.io/npm/dm/@codama/renderers-js.svg?style=flat
[npm-image]: https://img.shields.io/npm/v/@codama/renderers-js.svg?style=flat&label=%40codama%2Frenderers-js
[npm-url]: https://www.npmjs.com/package/@codama/renderers-js
This package generates JavaScript clients from your Codama IDLs. The generated clients are compatible with [`@solana/kit`](https://github.com/anza-xyz/kit).
## Installation
```sh
pnpm install @codama/renderers-js
```
## Usage
Add the following script to your Codama configuration file.
```json
{
"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](#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. |