build(deps-dev): bump @codama/renderers-js from 2.4.0 to 2.5.0

[dependabot]

Bumps @codama/renderers-js from 2.4.0 to 2.5.0.

Release notes

Sourced from @​codama/renderers-js's releases.

v2.5.0

Minor Changes

• #215 96acbc7 Thanks @​lorisleiva! - Widen the inputs accepted by generated instruction builders. Non-signer accounts now accept any InstructionAccountInput — i.e. an Address, a ProgramDerivedAddress, any object exposing an address property (see HasAddress, which lets third-party wrappers such as web3.js's PublicKey be passed directly), or an account meta such as { address, role: AccountRole.WRITABLE } to override the role declared by the IDL. Signer accounts accept any InstructionSignerInput — i.e. a TransactionSigner or an AccountSignerMeta. The type parameters of instruction builders and of their input types now capture the input value provided for each account, rather than its address, so that the account metas of the returned instruction reflect the exact values provided (e.g. an inline role: AccountRole.READONLY override resolves to a ReadonlyAccount). Instruction builders also forward each account's signer flag to getAccountMetaFactory. As a result, signers provided for non-signer accounts now merely carry their address instead of being attached as signers, and a value that cannot sign provided for a signer account fails with a dedicated error. Accounts whose bump seed is consumed by an argument no longer require a ProgramDerivedAddress at the type level; at runtime, providing a plain address for such an account throws unless the dependent argument is provided explicitly.

  Note that call sites providing explicit type arguments to instruction builders or their input types (e.g. getTransferInstruction<'1111', '2222'>(...) or TransferInput<'1111'>) need updating since these type parameters now expect input types rather than address strings (e.g. Address<'1111'>). Generated code now requires @solana/kit ^8.3.0, and the default @solana/* dependency versions written to package.json have been bumped accordingly.

• #216 369f05d Thanks @​lorisleiva! - Remaining accounts provided via the instruction input now accept the same inputs as instruction accounts — i.e. InstructionAccountInput for non-signer remaining accounts, InstructionSignerInput for signer remaining accounts, and the union of both for remaining accounts that may or may not be signers — and are converted to account metas by the same getAccountMeta helper. As a result, addresses are extracted from any address-carrying value (including third-party wrappers such as web3.js's PublicKey), explicit account metas override the role derived from the IDL, signers merely carry their address for non-signer remaining accounts, and values that cannot sign are rejected for signer remaining accounts. Remaining accounts backed by an existing instruction argument remain typed by that argument.

Patch Changes

• #217 eab516f Thanks @​lorisleiva! - Fix the preferRoot kit import strategy leaking into subsequent renders within the same process. Resolving imports with that strategy used to mutate the shared default module map, so that any later render using the rootOnly strategy would import program client helpers from @solana/program-client-core instead of @solana/kit/program-client-core.

Changelog

Sourced from @​codama/renderers-js's changelog.

2.5.0

Minor Changes

• #215 96acbc7 Thanks @​lorisleiva! - Widen the inputs accepted by generated instruction builders. Non-signer accounts now accept any InstructionAccountInput — i.e. an Address, a ProgramDerivedAddress, any object exposing an address property (see HasAddress, which lets third-party wrappers such as web3.js's PublicKey be passed directly), or an account meta such as { address, role: AccountRole.WRITABLE } to override the role declared by the IDL. Signer accounts accept any InstructionSignerInput — i.e. a TransactionSigner or an AccountSignerMeta. The type parameters of instruction builders and of their input types now capture the input value provided for each account, rather than its address, so that the account metas of the returned instruction reflect the exact values provided (e.g. an inline role: AccountRole.READONLY override resolves to a ReadonlyAccount). Instruction builders also forward each account's signer flag to getAccountMetaFactory. As a result, signers provided for non-signer accounts now merely carry their address instead of being attached as signers, and a value that cannot sign provided for a signer account fails with a dedicated error. Accounts whose bump seed is consumed by an argument no longer require a ProgramDerivedAddress at the type level; at runtime, providing a plain address for such an account throws unless the dependent argument is provided explicitly.

  Note that call sites providing explicit type arguments to instruction builders or their input types (e.g. getTransferInstruction<'1111', '2222'>(...) or TransferInput<'1111'>) need updating since these type parameters now expect input types rather than address strings (e.g. Address<'1111'>). Generated code now requires @solana/kit ^8.3.0, and the default @solana/* dependency versions written to package.json have been bumped accordingly.

• #216 369f05d Thanks @​lorisleiva! - Remaining accounts provided via the instruction input now accept the same inputs as instruction accounts — i.e. InstructionAccountInput for non-signer remaining accounts, InstructionSignerInput for signer remaining accounts, and the union of both for remaining accounts that may or may not be signers — and are converted to account metas by the same getAccountMeta helper. As a result, addresses are extracted from any address-carrying value (including third-party wrappers such as web3.js's PublicKey), explicit account metas override the role derived from the IDL, signers merely carry their address for non-signer remaining accounts, and values that cannot sign are rejected for signer remaining accounts. Remaining accounts backed by an existing instruction argument remain typed by that argument.

Patch Changes

• #217 eab516f Thanks @​lorisleiva! - Fix the preferRoot kit import strategy leaking into subsequent renders within the same process. Resolving imports with that strategy used to mutate the shared default module map, so that any later render using the rootOnly strategy would import program client helpers from @solana/program-client-core instead of @solana/kit/program-client-core.

Commits

• 454e169 [2.x] Release package (#218)
• 979b2b8 Adopt the shared release workflow with Trusted Publishing (#219)
• 369f05d Accept the same inputs for remaining accounts as for instruction accounts (#216)
• 96acbc7 Widen the inputs accepted by generated instruction builders (#215)
• eab516f Fix the preferRoot import strategy leaking into subsequent renders (#217)
• d9ef478 Bump @​solana/codecs-strings from 7.1.1 to 8.0.0 (#206)
• 1c9f266 Bump oxlint-tsgolint from 0.23.0 to 7.0.2001 (#205)
• 2cfc523 Adopt the release-tools automation (#214)
• d1f9bc8 Bump oxfmt from 0.64.0 to 0.65.0 (#213)
• fec92fa Bump @​types/node from 26.2.0 to 26.3.0 (#212)
• Additional commits viewable in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for @​codama/renderers-js since your current version.