chore(deps): bump the cli-dependencies group across 1 directory with 7 updates

[dependabot]

Bumps the cli-dependencies group with 7 updates in the /cli directory:

Package	From	To
@stellar/stellar-sdk	16.2.0	17.0.0
commander	12.1.0	15.0.0
dotenv	16.6.1	17.4.2
chalk	5.6.2	6.0.0
conf	12.0.0	15.1.0
@types/node	20.19.43	26.2.0
typescript	5.9.3	7.0.2

Updates @stellar/stellar-sdk from 16.2.0 to 17.0.0

Release notes

Sourced from @​stellar/stellar-sdk's releases.

v17.0.0

v17.0.0

Breaking Changes

• engines.node is now >=22.12.0, up from >=22.0.0. The CommonJS build require()s ESM-only dependencies, and require(esm) is only unflagged from Node 22.12.0, so on Node 22.0–22.11 require("@stellar/stellar-sdk") fails with ERR_REQUIRE_ESM. Installing on one of those versions now produces an EBADENGINE warning instead of a package that cannot be required. Nothing changes for ESM consumers, or on Node 22.12 and later (#1667).

• Public APIs use Uint8Array instead of Node's Buffer (#1457). Methods that returned Buffer (e.g. hash(), Keypair's sign/rawPublicKey/rawSecretKey, StrKey.decode*, Transaction.hash(), rpc.Server.getContractWasmByHash, getLiquidityPoolId(), AuthEntrySignature.signature, and the signing payload passed to a SigningCallback) now return a plain Uint8Array, so Buffer-only conveniences like .toString("hex") and .equals() on results must be replaced — see docs/migration/uint8array-migration.md for method-by-method recipes. Byte inputs still accept Buffer (it's a Uint8Array subclass), with three exceptions: a SigningCallback may no longer resolve to a raw ArrayBuffer (wrap it in a Uint8Array), SorobanDataBuilder's constructor no longer accepts non-Uint8Array typed arrays, and Memo.text no longer accepts a plain number[] (https://github.com/stellar/js-stellar-sdk/blob/HEAD/see the next entry). The buffer dependency is gone (base32.js, which needed a Buffer global, is replaced by @exodus/bytes), and browsers/edge runtimes need no Buffer polyfill. Note that DecoratedSignature.signature and .hint did not become raw bytes despite the name the first shares with AuthEntrySignature.signature — they are xdr.Signature / xdr.SignatureHint wrappers, unwrapped with .toBytes() (see docs/migration/xdr-migration.md § 6).

• Memo.text no longer accepts a plain number[]. Pass new Uint8Array(arr) instead (#1457). Through 16.2.0 it took a string, a plain array, or a Buffer, and rejected a bare Uint8Array. A Uint8Array is now the canonical byte input, and a plain array is the only input lost. Memo.text([]) was a valid zero-byte memo and now throws. The error message is unchanged (https://github.com/stellar/js-stellar-sdk/blob/HEAD/`Expects string or Uint8Array, max 28 bytes), so code that matches on it still works. See [docs/migration/uint8array-migration.md`](./docs/migration/uint8array-migration.md) § 3.

• The xdr namespace is rebuilt on @stellar/js-xdr v5, and every XDR value now has a different API (#1422). The wire format is unchanged: bytes and base64 written by older SDKs still decode, and vice versa. One caveat: v17 rejects malformed base64 outright, where v16's Buffer.from(str, "base64") silently dropped any character outside the alphabet (#1666). Any code that reads or builds xdr.* values must be updated. The main shifts:

  • Start here: docs/migration/xdr-migration.md covers every change below with before/after examples and a quick-reference table.
  • Unions are discriminated classes. .switch() becomes a .type string literal, arm getters like .contractData() become properties, and new xdr.LedgerEntryData(disc, val) becomes a factory call such as xdr.LedgerEntryData.contractData(val). The legacy new form throws a TypeError naming the factory method to call (#1658).
  • Enums are singletons, not factory calls: xdr.ContractDataDurability.persistent() becomes xdr.ContractDataDurability.persistent.
  • Primitives are plain JS values. Integers are number or bigint instead of class wrappers, anonymous opaque fields are Uint8Array, LargeInt subclasses are gone, and fields are readonly.
  • Named byte aliases (Hash, Signature, AssetCode4, PoolId, ContractId, …) are classes wrapping the bytes, not bare Uint8Array. They take raw bytes or a string on the way in and validate length at construction; read the bytes back with .toBytes(). The string form is hex, except for AssetCode4 / AssetCode12, which take the asset code as ASCII text and zero-pad it (new xdr.AssetCode4("USD")). This includes uint256, whose class is named Uint256Bytes because xdr.Uint256 is the bigint wrapper over Uint256Parts — it covers the ed25519 keys, salts, and nonces on PublicKey (and its alias AccountId), SignerKey, MuxedAccount, MuxedAccountMed25519, MuxedEd25519Account, TransactionV0, SignerKeyEd25519SignedPayload, ContractIdPreimageFromAddress, ClaimOfferAtomV0, and the Hello, DontHave, and StellarMessage overlay messages. A wrapper is not a Uint8Array: it has no .length, and Array.from() on one returns [], so compare two of them with .equals().
  • Absent optional fields decode to null instead of undefined, so === undefined checks silently stop matching. Prefer == null.
  • Acronyms in method names collapse to single-initial-cap form, with no back-compat aliases (e.g. validateXDR() is now validateXdr()). This reaches beyond the xdr namespace to the wrapper classes: Transaction.toXDR(), TransactionBuilder.fromXDR(), Operation.fromXDRObject(), Asset.toXDRObject(), contract.AssembledTransaction.toXDR() and others all gained the Xdr spelling.
  • Struct field names are unchanged, but a few type names moved: UInt128Parts / UInt256Parts are now Uint128Parts / Uint256Parts, ThresholdIndices is now ThresholdIndexes, and the typedef aliases Duration, TimePoint, SequenceNumber, ScVec, ScMap, LedgerEntryChanges, ContractCostParams, SorobanAuthorizationEntries, ScString, ScSymbol, String32, String64, and SponsorshipDescriptor are gone in favor of what they stood for.
  • New: toJson() / fromJson() for SEP-0051 JSON, toXdrObject() / fromXdrObject() on XDR values, and equals() for structural comparison. Failures throw xdr.XdrError, which is now exported.
  • Removed: Reader and Writer; the v4 runtime type constructors (Hyper, UnsignedHyper, Option, Opaque, VarOpaque, XDRArray, XDRString, Bool, SignedInt, UnsignedInt), plus top-level Hyper / UnsignedHyper / cereal; and xdr.scvSortedMap (use the top-level scvSortedMap).
  • ScInt and XdrLargeInt lost their .int property; read .value (a bigint) instead, and note valueOf() now returns a bigint.

• Rebuilding the XDR layer changed a few SDK-level behaviors that don't involve typing xdr. yourself. Most of these fail silently, so they won't surface as compile errors (#1422):

  • scValToNative returns a Uint8Array for an scvString whose contents aren't valid UTF-8. It previously always returned a string, substituting U+FFFD — its byte-returning branch was unreachable. Guards like typeof result === "string" and calls like result.startsWith(...) are now data-dependent. (scvSymbol follows the same rule, but the host restricts symbols to [_0-9A-Za-z], so a symbol that came off the network always decodes to a string.) The same applies to contract.Spec.scValToNative and contract.Spec.funcResToNative for Bytes / BytesN, which return Uint8Array; those are generically typed, so TypeScript won't flag it.
  • Operation.fromXdrObject decodes manageData's name, setOptions's homeDomain, and revokeSponsorship's data-entry name as UTF-8 rather than ASCII. Only bytes ≥ 0x80 decode differently, and stellar-core rejects those in all three fields, so no valid operation is affected — but snapshots taken over synthetic or forged XDR will change ([0xC3, 0xA9] now decodes to "é", was "C)"). See the migration guide for the round-trip details.
  • SorobanDataBuilder still chains, and its setters still mutate the builder. What changed is one level down: because XDR fields are readonly now, setReadOnly / setReadWrite / setResources replace the internal data rather than edit it in place. Two consequences: a footprint you captured from getFootprint() before one of those calls is a stale snapshot, so re-read it afterward; and you can no longer configure the builder through that object (builder.getFootprint().readOnly(keys)) — call the setters instead.
  • MuxedAccount.setId no longer mutates an xdr.MuxedAccount you already obtained from toXdrObject(); call it again after setId.

• HorizonApi.TransactionFailedExtras's result_codes.operations is now optional (operations?: string[]). Horizon omits the field when a transaction fails a transaction-level check (e.g. tx_bad_seq) and no operations were evaluated, so the type now matches the wire format. Under strictNullChecks, unguarded reads of the raw response (extras.result_codes.operations.map(...)) no longer compile; guard them, or use TransactionFailedError.getResultCodes(), which normalizes the omitted field to [] (#1527).

• CAP-71 SOROBAN_CREDENTIALS_ADDRESS_V2 credentials are now the default, on both ends of the auth flow. rpc.Server.simulateTransaction's useUpgradedAuth and authorizeInvocation's authV2 both default to true, so simulation asks RPC to record v2 entries and authorizeInvocation builds them. Pass false to either one for the legacy SOROBAN_CREDENTIALS_ADDRESS format. Both flags are transitional and become no-ops when v2 is mandatory in protocol 28. Two consequences: code that reads the credential arm by hand must handle addressV2 and not just address (or use inspectAuthEntry), and a hand-rolled signer that hardcodes the legacy ENVELOPE_TYPE_SOROBAN_AUTHORIZATION preimage now produces signatures the network rejects, so use buildAuthorizationEntryPreimage or authorizeEntry, which pick the address-bound payload off the entry. SDK-driven signing (contract.Client, authorizeEntry, signAuthEntries) needs no change (#1562).

• simulateTransaction now always sends useUpgradedAuth in the JSON-RPC request. It previously omitted the field when the flag was unset (#1562).

Added

• rpc.Server.getExternalRefWasmHash(ref): resolves a CAP-85 external executable reference to the 32-byte Wasm hash it names by reading the persistent tag entry on the owner contract (#1577).
• The XDR schema covers CAP-83 (empty transaction set values), adding a stellarValueEmptyTxSet arm to xdr.StellarValueType (#1577).
• The XDR schema covers CAP-85 (external contract executables), adding a contractExecutableExternalRef arm to xdr.ContractExecutableType — an executableOwner address plus a tag — and an scvExecutableTag arm to xdr.ScValType (#1577).
• Operation.createCustomContract can deploy from a CAP-85 external executable reference. Pass externalRef — either {owner, tag} (owner as a strkey or Address, tag as a string or raw bytes) or an xdr.ContractExecutableExternalRef pulled from an existing contract instance — instead of wasmHash; the two options are mutually exclusive. The owner must be a contract, since only a contract can hold the persistent tag entry that names the WASM, and a binary tag passes through undecoded (#1665).
• contract.Client.deploy accepts the same externalRef option in place of wasmHash. The reference is resolved on-chain (via rpc.Server.getExternalRefWasmHash) to fetch the contract spec for constructor arguments, while the deploy operation itself carries the external reference, so the deployed contract keeps following the tag. Generated bindings (BindingGenerator) emit a deploy method with the same option, and the ExternalExecutableRef type is exported from the package root and from @stellar/stellar-sdk/contract (#1665).
• xdr.encodeArray / xdr.decodeArray: encode or decode a whole list of XDR values as one length-prefixed blob (a 4-byte count, then the elements). This is the wire format of the array typedefs the XDR rebuild removed (see Breaking Changes), so xdr.LedgerEntryChanges.fromXDR(feeMetaXdr, "base64") becomes xdr.decodeArray(xdr.LedgerEntryChange, feeMetaXdr, "base64"). Both work with any XDR class and take an optional XdrArrayOptions with maxLength (element-count cap, for bounded arrays like peers<25>) and maxDepth (#1660).
• rpc.Server.prepareTransaction takes an optional useUpgradedAuth parameter, since its internal simulation now requests v2 credentials by default. Pass false for the legacy v1 format (#1562).

Changed

• scValToNative converts an scvExecutableTag to its tag: a string when the bytes are valid UTF-8, otherwise the raw bytes (same rule as scvString) (#1577).
• buildInvocationTree renders CAP-85 external-executable creations instead of throwing. CreateInvocation.type gains an "external" case, whose details live in a new external field (owner, tag, address, salt, and constructorArgs for CREATE_CONTRACT_V2). tag is string | Uint8Array — an executable tag is an unbounded SCString, so a binary one is returned as raw bytes rather than lossily decoded (#1577).
• StrKey.decode* and the underlying decodeCheck now validate the encoded string's length against the requested strkey type before decoding it. Two consequences: a long attacker-supplied string is rejected up front instead of driving a full base32 decode plus canonical re-encode, and a strkey whose payload is the wrong size for its type now throws instead of returning a mis-sized buffer (previously, a 37-byte payload encoded as an ed25519PublicKey strkey decoded to 37 bytes and only failed later, if at all). Inputs that were already invalid may now report a length error rather than a checksum or version-byte error (#1583).
• contract.Client.from and rpc.Server.getContractWasmByContractId support contracts created from a CAP-85 external executable reference. The reference names an owner contract and a tag; the owner holds a persistent contract data entry keyed by that tag whose value is the Wasm hash, so both methods resolve that entry and then load the Wasm as usual (#1577).
• contract.Client.txFromJSON is now txFromJson, and generated bindings' fromJSON is now fromJson, matching the toJson/fromJson naming used across the XDR layer. Both keep a deprecated alias, so existing calls still work (#1422).

Fixed

• StrKey.decodeSignedPayload and StrKey.isValidSignedPayload now validate the framing inside a P... strkey: the declared payload length must be 1-64, must match the number of payload bytes present, and the padding must be zero. The three SEP-23 invalid signed-payload test cases — length prefix shorter than the payload, longer than the payload, and missing zero padding — were previously accepted (#1588).
• StrKey.decodeClaimableBalance and StrKey.isValidClaimableBalance now validate the discriminant byte that leads a B... strkey. CLAIMABLE_BALANCE_ID_TYPE_V0 (0) is the only case ClaimableBalanceID declares, so the XDR decoder has always refused anything else — but the strkey checksum covers whatever byte is present, so a B... key with an unknown discriminant was decoded and reported valid.

... (truncated)

Changelog

Sourced from @​stellar/stellar-sdk's changelog.

v17.0.0

Breaking Changes

• engines.node is now >=22.12.0, up from >=22.0.0. The CommonJS build require()s ESM-only dependencies, and require(esm) is only unflagged from Node 22.12.0, so on Node 22.0–22.11 require("@stellar/stellar-sdk") fails with ERR_REQUIRE_ESM. Installing on one of those versions now produces an EBADENGINE warning instead of a package that cannot be required. Nothing changes for ESM consumers, or on Node 22.12 and later (#1667).

• Public APIs use Uint8Array instead of Node's Buffer (#1457). Methods that returned Buffer (e.g. hash(), Keypair's sign/rawPublicKey/rawSecretKey, StrKey.decode*, Transaction.hash(), rpc.Server.getContractWasmByHash, getLiquidityPoolId(), AuthEntrySignature.signature, and the signing payload passed to a SigningCallback) now return a plain Uint8Array, so Buffer-only conveniences like .toString("hex") and .equals() on results must be replaced — see docs/migration/uint8array-migration.md for method-by-method recipes. Byte inputs still accept Buffer (it's a Uint8Array subclass), with three exceptions: a SigningCallback may no longer resolve to a raw ArrayBuffer (wrap it in a Uint8Array), SorobanDataBuilder's constructor no longer accepts non-Uint8Array typed arrays, and Memo.text no longer accepts a plain number[] (https://github.com/stellar/js-stellar-sdk/blob/main/see the next entry). The buffer dependency is gone (base32.js, which needed a Buffer global, is replaced by @exodus/bytes), and browsers/edge runtimes need no Buffer polyfill. Note that DecoratedSignature.signature and .hint did not become raw bytes despite the name the first shares with AuthEntrySignature.signature — they are xdr.Signature / xdr.SignatureHint wrappers, unwrapped with .toBytes() (see docs/migration/xdr-migration.md § 6).

• Memo.text no longer accepts a plain number[]. Pass new Uint8Array(arr) instead (#1457). Through 16.2.0 it took a string, a plain array, or a Buffer, and rejected a bare Uint8Array. A Uint8Array is now the canonical byte input, and a plain array is the only input lost. Memo.text([]) was a valid zero-byte memo and now throws. The error message is unchanged (https://github.com/stellar/js-stellar-sdk/blob/main/`Expects string or Uint8Array, max 28 bytes), so code that matches on it still works. See [docs/migration/uint8array-migration.md`](./docs/migration/uint8array-migration.md) § 3.

• The xdr namespace is rebuilt on @stellar/js-xdr v5, and every XDR value now has a different API (#1422). The wire format is unchanged: bytes and base64 written by older SDKs still decode, and vice versa. One caveat: v17 rejects malformed base64 outright, where v16's Buffer.from(str, "base64") silently dropped any character outside the alphabet (#1666). Any code that reads or builds xdr.* values must be updated. The main shifts:

  • Start here: docs/migration/xdr-migration.md covers every change below with before/after examples and a quick-reference table.
  • Unions are discriminated classes. .switch() becomes a .type string literal, arm getters like .contractData() become properties, and new xdr.LedgerEntryData(disc, val) becomes a factory call such as xdr.LedgerEntryData.contractData(val). The legacy new form throws a TypeError naming the factory method to call (#1658).
  • Enums are singletons, not factory calls: xdr.ContractDataDurability.persistent() becomes xdr.ContractDataDurability.persistent.
  • Primitives are plain JS values. Integers are number or bigint instead of class wrappers, anonymous opaque fields are Uint8Array, LargeInt subclasses are gone, and fields are readonly.
  • Named byte aliases (Hash, Signature, AssetCode4, PoolId, ContractId, …) are classes wrapping the bytes, not bare Uint8Array. They take raw bytes or a string on the way in and validate length at construction; read the bytes back with .toBytes(). The string form is hex, except for AssetCode4 / AssetCode12, which take the asset code as ASCII text and zero-pad it (new xdr.AssetCode4("USD")). This includes uint256, whose class is named Uint256Bytes because xdr.Uint256 is the bigint wrapper over Uint256Parts — it covers the ed25519 keys, salts, and nonces on PublicKey (and its alias AccountId), SignerKey, MuxedAccount, MuxedAccountMed25519, MuxedEd25519Account, TransactionV0, SignerKeyEd25519SignedPayload, ContractIdPreimageFromAddress, ClaimOfferAtomV0, and the Hello, DontHave, and StellarMessage overlay messages. A wrapper is not a Uint8Array: it has no .length, and Array.from() on one returns [], so compare two of them with .equals().
  • Absent optional fields decode to null instead of undefined, so === undefined checks silently stop matching. Prefer == null.
  • Acronyms in method names collapse to single-initial-cap form, with no back-compat aliases (e.g. validateXDR() is now validateXdr()). This reaches beyond the xdr namespace to the wrapper classes: Transaction.toXDR(), TransactionBuilder.fromXDR(), Operation.fromXDRObject(), Asset.toXDRObject(), contract.AssembledTransaction.toXDR() and others all gained the Xdr spelling.
  • Struct field names are unchanged, but a few type names moved: UInt128Parts / UInt256Parts are now Uint128Parts / Uint256Parts, ThresholdIndices is now ThresholdIndexes, and the typedef aliases Duration, TimePoint, SequenceNumber, ScVec, ScMap, LedgerEntryChanges, ContractCostParams, SorobanAuthorizationEntries, ScString, ScSymbol, String32, String64, and SponsorshipDescriptor are gone in favor of what they stood for.
  • New: toJson() / fromJson() for SEP-0051 JSON, toXdrObject() / fromXdrObject() on XDR values, and equals() for structural comparison. Failures throw xdr.XdrError, which is now exported.
  • Removed: Reader and Writer; the v4 runtime type constructors (Hyper, UnsignedHyper, Option, Opaque, VarOpaque, XDRArray, XDRString, Bool, SignedInt, UnsignedInt), plus top-level Hyper / UnsignedHyper / cereal; and xdr.scvSortedMap (use the top-level scvSortedMap).
  • ScInt and XdrLargeInt lost their .int property; read .value (a bigint) instead, and note valueOf() now returns a bigint.

• Rebuilding the XDR layer changed a few SDK-level behaviors that don't involve typing xdr. yourself. Most of these fail silently, so they won't surface as compile errors (#1422):

  • scValToNative returns a Uint8Array for an scvString whose contents aren't valid UTF-8. It previously always returned a string, substituting U+FFFD — its byte-returning branch was unreachable. Guards like typeof result === "string" and calls like result.startsWith(...) are now data-dependent. (scvSymbol follows the same rule, but the host restricts symbols to [_0-9A-Za-z], so a symbol that came off the network always decodes to a string.) The same applies to contract.Spec.scValToNative and contract.Spec.funcResToNative for Bytes / BytesN, which return Uint8Array; those are generically typed, so TypeScript won't flag it.
  • Operation.fromXdrObject decodes manageData's name, setOptions's homeDomain, and revokeSponsorship's data-entry name as UTF-8 rather than ASCII. Only bytes ≥ 0x80 decode differently, and stellar-core rejects those in all three fields, so no valid operation is affected — but snapshots taken over synthetic or forged XDR will change ([0xC3, 0xA9] now decodes to "é", was "C)"). See the migration guide for the round-trip details.
  • SorobanDataBuilder still chains, and its setters still mutate the builder. What changed is one level down: because XDR fields are readonly now, setReadOnly / setReadWrite / setResources replace the internal data rather than edit it in place. Two consequences: a footprint you captured from getFootprint() before one of those calls is a stale snapshot, so re-read it afterward; and you can no longer configure the builder through that object (builder.getFootprint().readOnly(keys)) — call the setters instead.
  • MuxedAccount.setId no longer mutates an xdr.MuxedAccount you already obtained from toXdrObject(); call it again after setId.

• HorizonApi.TransactionFailedExtras's result_codes.operations is now optional (operations?: string[]). Horizon omits the field when a transaction fails a transaction-level check (e.g. tx_bad_seq) and no operations were evaluated, so the type now matches the wire format. Under strictNullChecks, unguarded reads of the raw response (extras.result_codes.operations.map(...)) no longer compile; guard them, or use TransactionFailedError.getResultCodes(), which normalizes the omitted field to [] (#1527).

• CAP-71 SOROBAN_CREDENTIALS_ADDRESS_V2 credentials are now the default, on both ends of the auth flow. rpc.Server.simulateTransaction's useUpgradedAuth and authorizeInvocation's authV2 both default to true, so simulation asks RPC to record v2 entries and authorizeInvocation builds them. Pass false to either one for the legacy SOROBAN_CREDENTIALS_ADDRESS format. Both flags are transitional and become no-ops when v2 is mandatory in protocol 28. Two consequences: code that reads the credential arm by hand must handle addressV2 and not just address (or use inspectAuthEntry), and a hand-rolled signer that hardcodes the legacy ENVELOPE_TYPE_SOROBAN_AUTHORIZATION preimage now produces signatures the network rejects, so use buildAuthorizationEntryPreimage or authorizeEntry, which pick the address-bound payload off the entry. SDK-driven signing (contract.Client, authorizeEntry, signAuthEntries) needs no change (#1562).

• simulateTransaction now always sends useUpgradedAuth in the JSON-RPC request. It previously omitted the field when the flag was unset (#1562).

Added

• rpc.Server.getExternalRefWasmHash(ref): resolves a CAP-85 external executable reference to the 32-byte Wasm hash it names by reading the persistent tag entry on the owner contract (#1577).
• The XDR schema covers CAP-83 (empty transaction set values), adding a stellarValueEmptyTxSet arm to xdr.StellarValueType (#1577).
• The XDR schema covers CAP-85 (external contract executables), adding a contractExecutableExternalRef arm to xdr.ContractExecutableType — an executableOwner address plus a tag — and an scvExecutableTag arm to xdr.ScValType (#1577).
• Operation.createCustomContract can deploy from a CAP-85 external executable reference. Pass externalRef — either {owner, tag} (owner as a strkey or Address, tag as a string or raw bytes) or an xdr.ContractExecutableExternalRef pulled from an existing contract instance — instead of wasmHash; the two options are mutually exclusive. The owner must be a contract, since only a contract can hold the persistent tag entry that names the WASM, and a binary tag passes through undecoded (#1665).
• contract.Client.deploy accepts the same externalRef option in place of wasmHash. The reference is resolved on-chain (via rpc.Server.getExternalRefWasmHash) to fetch the contract spec for constructor arguments, while the deploy operation itself carries the external reference, so the deployed contract keeps following the tag. Generated bindings (BindingGenerator) emit a deploy method with the same option, and the ExternalExecutableRef type is exported from the package root and from @stellar/stellar-sdk/contract (#1665).
• xdr.encodeArray / xdr.decodeArray: encode or decode a whole list of XDR values as one length-prefixed blob (a 4-byte count, then the elements). This is the wire format of the array typedefs the XDR rebuild removed (see Breaking Changes), so xdr.LedgerEntryChanges.fromXDR(feeMetaXdr, "base64") becomes xdr.decodeArray(xdr.LedgerEntryChange, feeMetaXdr, "base64"). Both work with any XDR class and take an optional XdrArrayOptions with maxLength (element-count cap, for bounded arrays like peers<25>) and maxDepth (#1660).
• rpc.Server.prepareTransaction takes an optional useUpgradedAuth parameter, since its internal simulation now requests v2 credentials by default. Pass false for the legacy v1 format (#1562).

Changed

• scValToNative converts an scvExecutableTag to its tag: a string when the bytes are valid UTF-8, otherwise the raw bytes (same rule as scvString) (#1577).
• buildInvocationTree renders CAP-85 external-executable creations instead of throwing. CreateInvocation.type gains an "external" case, whose details live in a new external field (owner, tag, address, salt, and constructorArgs for CREATE_CONTRACT_V2). tag is string | Uint8Array — an executable tag is an unbounded SCString, so a binary one is returned as raw bytes rather than lossily decoded (#1577).
• StrKey.decode* and the underlying decodeCheck now validate the encoded string's length against the requested strkey type before decoding it. Two consequences: a long attacker-supplied string is rejected up front instead of driving a full base32 decode plus canonical re-encode, and a strkey whose payload is the wrong size for its type now throws instead of returning a mis-sized buffer (previously, a 37-byte payload encoded as an ed25519PublicKey strkey decoded to 37 bytes and only failed later, if at all). Inputs that were already invalid may now report a length error rather than a checksum or version-byte error (#1583).
• contract.Client.from and rpc.Server.getContractWasmByContractId support contracts created from a CAP-85 external executable reference. The reference names an owner contract and a tag; the owner holds a persistent contract data entry keyed by that tag whose value is the Wasm hash, so both methods resolve that entry and then load the Wasm as usual (#1577).
• contract.Client.txFromJSON is now txFromJson, and generated bindings' fromJSON is now fromJson, matching the toJson/fromJson naming used across the XDR layer. Both keep a deprecated alias, so existing calls still work (#1422).

Fixed

• StrKey.decodeSignedPayload and StrKey.isValidSignedPayload now validate the framing inside a P... strkey: the declared payload length must be 1-64, must match the number of payload bytes present, and the padding must be zero. The three SEP-23 invalid signed-payload test cases — length prefix shorter than the payload, longer than the payload, and missing zero padding — were previously accepted (#1588).
• StrKey.decodeClaimableBalance and StrKey.isValidClaimableBalance now validate the discriminant byte that leads a B... strkey. CLAIMABLE_BALANCE_ID_TYPE_V0 (0) is the only case ClaimableBalanceID declares, so the XDR decoder has always refused anything else — but the strkey checksum covers whatever byte is present, so a B... key with an unknown discriminant was decoded and reported valid.
• The published type declarations no longer reference types the package doesn't provide, so the SDK compiles under skipLibCheck: false with no @types packages installed. @types/json-schema moved from devDependencies to dependencies, since contract.Spec.jsonSchema returns a JSONSchema7 (previously Cannot find module 'json-schema'); and contract.SentTransaction.Errors' three error classes are declared instead of inlined, which stops TypeScript emitting their inferred static side and with it a NodeJS.CallSite reference from @types/node (previously Cannot find namespace 'NodeJS'). No runtime or API change (#1626).

... (truncated)

Commits

• f17ef09 chore(release): prepare v17.0.0 (#1675)
• d6b08c7 docs: correct examples and claims that don't match the v17 API (#1673)
• 6f44dd3 perf(base): fast base64 helpers to replace uint8array-extras codec (#1668)
• 0f74fc5 feat: accept CAP-85 external executable refs in createCustomContract (#1665)
• 264033e fix: declare node >=22.12.0, where the cjs build can be required (#1667)
• bff0ef5 fix(xdr): throw XdrError for malformed hex, base64, and escapes (#1666)
• 27de307 Release v17.0.0 rc.2 (#1662)
• ddf86a9 docs: point the Uint8Array migration guide at SDK byte helpers (#1661)
• 1c83252 feat(xdr): add encodeArray / decodeArray for length-prefixed XDR arrays (...
• 1fb4f96 docs(xdr): correct the Uint8Array claim for byte wrapper types (#1654)
• Additional commits viewable in compare view

Updates commander from 12.1.0 to 15.0.0

Release notes

Sourced from commander's releases.

v15.0.0

Commander 15 is ESM only. This is expected to be seamless for ESM consumers, but some CommonJS consumers may hit issues with tooling requiring configuration for ESM-only dependencies. See Migration Tips below.

The release of Commander 15 moves Commander 14 into maintenance. Commander 14 will get security updates for 12 months (to May 2027). For more info see Release Policy.

Added

• show excess command-arguments in error message (#2384)

Fixed

• Breaking: only lone --no-* option sets default option value to true, default not implicitly set when define both positive and negative option in either order (#2405)
• update example to use compatible character for MINGW64 (#2475)

Changed

• Breaking: migrated Commander implementation from CommonJS to ESM (#2464)
• Breaking: Commander 15 requires Node.js v22.12.0 or higher (for require(esm)).
• dev: switch tests from Jest to node:test test runner (#2463)

Deleted

• Breaking: removed deprecated export of commander/esm.mjs (#2464)

Migration Tips

Commander 15 is ESM only, but this does not mean you need to migrate to ESM to use it. Importing ESM from CommonJS is supported by Node.js, and Bun, and Deno. Hopefully it Just Works for you! However, you may be using a different runtime or some other part of your setup that may not yet natively support importing ESM from CommonJS, such as your testing framework or bundler.

If you have problems using Commander 15 in your environment, one option is stay on Commander 14 for now. Commander 14 will get security updates until May 2027 and things will hopefully improve for your setup in the meantime.

v15.0.0-0

Commander 15 is ESM only. This is expected to be seamless for ESM consumers, but some CommonJS consumers may hit issues with tooling requiring configuration for ESM-only dependencies. See Migration Tips below.

The release of Commander 15 in May 2026 will move Commander 14 into maintenance. Commander 14 will get security updates for 12 months (to May 2027). For more info see Release Policy.

Added

• show excess command-arguments in error message (#2384)

Fixed

• Breaking: only lone --no-* option sets default option value to true, default not implicitly set when define both positive and negative option in either order (#2405)
• update example to use compatible character for MINGW64 (#2475)

... (truncated)

Changelog

Sourced from commander's changelog.

[15.0.0] (2026-05-29)

Commander 15 is ESM only. This is expected to be seamless for ESM consumers, but some CommonJS consumers may hit issues with tooling requiring configuration for ESM-only dependencies. See Migration Tips below.

The release of Commander 15 moves Commander 14 into maintenance. Commander 14 will get security updates for 12 months (to May 2027). For more info see Release Policy.

Added

• show excess command-arguments in error message (#2384)

Fixed

• Breaking: only lone --no-* option sets default option value to true, default not implicitly set when define both positive and negative option in either order (#2405)
• update example to use compatible character for MINGW64 (#2475)

Changed

• Breaking: migrated Commander implementation from CommonJS to ESM (#2464)
• Breaking: Commander 15 requires Node.js v22.12.0 or higher (for require(esm)).
• dev: switch tests from Jest to node:test test runner (#2463)

Deleted

• Breaking: removed deprecated export of commander/esm.mjs (#2464)

Migration Tips

Commander 15 is ESM only, but this does not mean you need to migrate to ESM to use it. Importing ESM from CommonJS is supported by Node.js, and Bun, and Deno. Hopefully it Just Works for you! However, you may be using a different runtime or some other part of your setup that may not yet natively support importing ESM from CommonJS, such as your testing framework or bundler.

If you have problems using Commander 15 in your environment, one option is stay on Commander 14 for now. Commander 14 will get security updates until May 2027 and things will hopefully improve for your setup in the meantime.

[15.0.0-0] (2026-02-22)

(Released as 15.0.0)

[14.0.3] (2026-01-31)

Added

• Release Policy document (#2462)

Changes

• old major versions now supported for 12 months instead of just previous major version, to give predictable end-of-life date (#2462)
• clarify typing for deprecated callback parameter to .outputHelp() (#2427)

... (truncated)

Commits

• ba6d13d Fix release dates in changelog (#2523)
• a752ed9 Pin GitHub actions with hash (#2521)
• 74d5dfe Drop EOL node 20 from test matrix, and add node 26 (#2520)
• 6df9b68 Update details for 15.0.0 release (#2519)
• 01ce5d0 Remove jest esm examples (#2517)
• d785d8b Update dependencies (#2518)
• 9098b48 Update dependencies (#2506)
• 373f660 Use node:util stripVTControlCharacters instead of own code (#2486)
• 987f289 Use simple match in test (to avoid warning about expensive regex) (#2485)
• 0ea3bb3 Update dependecies and lint (#2489)
• Additional commits viewable in compare view

Updates dotenv from 16.6.1 to 17.4.2

Changelog

Sourced from dotenv's changelog.

17.4.2 (2026-04-12)

Changed

• Improved skill files - tightened up details (#1009)

17.4.1 (2026-04-05)

Changed

• Change text injecting to injected (#1005)

17.4.0 (2026-04-01)

Added

• Add skills/ folder with focused agent skills: skills/dotenv/SKILL.md (core usage) and skills/dotenvx/SKILL.md (encryption, multiple environments, variable expansion) for AI coding agent discovery via the skills.sh ecosystem (npx skills add motdotla/dotenv)

Changed

• Tighten up logs: ◇ injecting env (14) from .env (#1003)

17.3.1 (2026-02-12)

Changed

• Fix as2 example command in README and update spanish README

17.3.0 (2026-02-12)

Added

• Add a new README section on dotenv’s approach to the agentic future.

Changed

• Rewrite README to get humans started more quickly with less noise while simultaneously making more accessible for llms and agents to go deeper into details.

17.2.4 (2026-02-05)

Changed

• Make DotenvPopulateInput accept NodeJS.ProcessEnv type (#915)

• Give back to dotenv by checking out my newest project vestauth. It is auth for agents. Thank you for using my software.

17.2.3 (2025-09-29)

Changed

• Fixed typescript error definition (#912)

... (truncated)

Commits

• f116f70 17.4.2
• 3a81612 fix visual order of faq
• 13f55a8 Merge branch 'skill'
• 4bbbf73 reorganize faq
• c3da64b Merge pull request #1009 from motdotla/skill
• 6f743b1 update source
• fc2c624 update skill
• 972315b Tighten up skill
• 2795fce reorganize faq
• d5495d4 adjust skill
• Additional commits viewable in compare view

Updates chalk from 5.6.2 to 6.0.0

Release notes

Sourced from chalk's releases.

v6.0.0

Breaking

• Require Node.js 22 8a94e0e

Improvements

• Add underline styles and underline colors (#689) 4c304dd
• Improve performance 5729845 fa5cff2

Fixes

• Treat a numeric FORCE_COLOR as an exact level (#688) e912931
• Downsample ansi256() and bgAnsi256() to 16 colors at level 1 (#687) ff549c5

---

chalk/chalk@v5.6.2...v6.0.0

Commits

• 661317e 6.0.0
• 5729845 Improve performance
• 4...

  Description has been truncated

[dependabot]

Labels

The following labels could not be found: cli, dependencies. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.