Skip to content

build(deps-dev): bump @codama/renderers-rust from 1.1.3 to 3.0.0#339

Open
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/npm_and_yarn/codama/renderers-rust-3.0.0
Open

build(deps-dev): bump @codama/renderers-rust from 1.1.3 to 3.0.0#339
dependabot[bot] wants to merge 1 commit intomainfrom
dependabot/npm_and_yarn/codama/renderers-rust-3.0.0

Conversation

@dependabot
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Mar 11, 2026

Bumps @codama/renderers-rust from 1.1.3 to 3.0.0.

Release notes

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

v3.0.0

Major Changes

  • #92 4af6c06 Thanks @​grod220! - Removed default serde support and replaced kaigan with spl-collections

    BREAKING CHANGES:

    • Generated variable-sized string/vector wrappers now come from spl-collections instead of kaigan. If you have handwritten code that references these generated wrapper types, update those imports and usages after regenerating your client:

      • kaigan::types::RemainderStr -> spl_collections::TrailingStr
      • kaigan::types::RemainderVec<T> -> spl_collections::TrailingVec<T>
      • kaigan::types::U8PrefixString, U16PrefixString, U64PrefixString -> spl_collections::U8PrefixedStr, U16PrefixedStr, U64PrefixedStr
      • kaigan::types::U8PrefixVec<T>, U16PrefixVec<T>, U64PrefixVec<T> -> spl_collections::U8PrefixedVec<T>, U16PrefixedVec<T>, U64PrefixedVec<T>
    • serde is no longer part of the default or recommended generated client surface. The previous default derives on wrapper types were misleading because their serde representation does not match the Borsh/Wincode wire format.

    • If you still want serde derives for a separate JSON representation, you can opt in explicitly via traitOptions as shown below. This does not make the generated types serde-compatible with their Borsh/Wincode wire format, but you can define a handwritten implementation with your own serde mapping as needed.

        traitOptions: {
          baseDefaults: [
            'borsh::BorshSerialize',
            'borsh::BorshDeserialize',
    •   'serde::Serialize',
      
    •   'serde::Deserialize',
        'Clone',
        'Debug',
        'Eq',
        'PartialEq',
      ],
      
    • featureFlags: {

    •   serde: ['serde::Serialize', 'serde::Deserialize'],
      
    • }, }

      
      
  • #90 f214970 Thanks @​grod220! - Switch generated Rust code from solana_pubkey::Pubkey to solana_address::Address and update the default dependency set to newer Solana 3.x and borsh 1.0 versions. This affects generated program IDs, account/instruction types, PDA helpers, and public key literals, so downstream users may need to update imports and pubkey usage after regenerating clients.

v2.0.1

Patch Changes

v2.0.0

Major Changes

  • #85 44dacca Thanks @​lorisleiva! - Refactor renderVisitor to use crateFolder as its primary argument instead of the generated output path. The generated folder is now derived internally using a new generatedFolder option (defaults to 'src/generated'). Remove the crateFolder option as it is no longer needed.

    BREAKING CHANGES

... (truncated)

Changelog

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

3.0.0

Major Changes

  • #92 4af6c06 Thanks @​grod220! - Removed default serde support and replaced kaigan with spl-collections

    BREAKING CHANGES:

    • Generated variable-sized string/vector wrappers now come from spl-collections instead of kaigan. If you have handwritten code that references these generated wrapper types, update those imports and usages after regenerating your client:
      • kaigan::types::RemainderStr -> spl_collections::TrailingStr
      • kaigan::types::RemainderVec<T> -> spl_collections::TrailingVec<T>
      • kaigan::types::U8PrefixString, U16PrefixString, U64PrefixString -> spl_collections::U8PrefixedStr, U16PrefixedStr, U64PrefixedStr
      • kaigan::types::U8PrefixVec<T>, U16PrefixVec<T>, U64PrefixVec<T> -> spl_collections::U8PrefixedVec<T>, U16PrefixedVec<T>, U64PrefixedVec<T>
    • serde is no longer part of the default or recommended generated client surface. The previous default derives on wrapper types were misleading because their serde representation does not match the Borsh/Wincode wire format.
    • If you still want serde derives for a separate JSON representation, you can opt in explicitly via traitOptions as shown below. This does not make the generated types serde-compatible with their Borsh/Wincode wire format, but you can define a handwritten implementation with your own serde mapping as needed.
      traitOptions: {
        baseDefaults: [
          'borsh::BorshSerialize',
          'borsh::BorshDeserialize',
    +     'serde::Serialize',
    +     'serde::Deserialize',
          'Clone',
          'Debug',
          'Eq',
          'PartialEq',
        ],
    +   featureFlags: {
    +     serde: ['serde::Serialize', 'serde::Deserialize'],
    +   },
      }
  • #90 f214970 Thanks @​grod220! - Switch generated Rust code from solana_pubkey::Pubkey to solana_address::Address and update the default dependency set to newer Solana 3.x and borsh 1.0 versions. This affects generated program IDs, account/instruction types, PDA helpers, and public key literals, so downstream users may need to update imports and pubkey usage after regenerating clients.

2.0.1

Patch Changes

2.0.0

Major Changes

  • #85 44dacca Thanks @​lorisleiva! - Refactor renderVisitor to use crateFolder as its primary argument instead of the generated output path. The generated folder is now derived internally using a new generatedFolder option (defaults to 'src/generated'). Remove the crateFolder option as it is no longer needed.

    BREAKING CHANGES

    First argument of renderVisitor changed from output path to crate folder. The function now takes the crate folder (where Cargo.toml lives) and derives the generated output path internally.

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [@codama/renderers-rust](https://github.com/codama-idl/renderers-rust) from 1.1.3 to 3.0.0.
- [Release notes](https://github.com/codama-idl/renderers-rust/releases)
- [Changelog](https://github.com/codama-idl/renderers-rust/blob/main/CHANGELOG.md)
- [Commits](https://github.com/codama-idl/renderers-rust/commits/v3.0.0)

---
updated-dependencies:
- dependency-name: "@codama/renderers-rust"
  dependency-version: 3.0.0
  dependency-type: direct:development
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code labels Mar 11, 2026
@github-actions github-actions bot enabled auto-merge (squash) March 11, 2026 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants