[dependabot]

Bumps the stellar-sdk-scripts group with 1 update in the /scripts directory: @stellar/stellar-sdk.

Updates @stellar/stellar-sdk from 15.0.1 to 17.2.1

Release notes

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

v17.2.1

v17.2.1

Fixed

• Asset.compare() orders two assets with the same code by their issuers' key bytes, as stellar-core does, instead of by the G… strkey text. The two orders can differ, so getLiquidityPoolId() and new LiquidityPoolAsset() rejected some valid asset pairs as out of order (#1766).
• scvSortedMap() and nativeToScVal() now sort map keys in the order the Soroban host requires: by ScVal type, then by value. They previously compared the keys' native string forms, so address, bytes, and mixed-type keys could come out in an order the host rejects. A plain object's keys are now sorted after conversion, so { 10: …, 9: … } with u32 keys becomes [9, 10]. Maps that mix key types change order: scvString keys now come before scvSymbol keys, whatever their names (#1766).

Full Changelog: stellar/js-stellar-sdk@v17.2.0...v17.2.1

v17.2.0

v17.2.0

Added

• A stellar-contract-bindings-typescript binary implementing the Stellar CLI plugin convention, reachable as stellar contract bindings typescript. It delegates to stellar-js generate. The package also adds a stellar-sdk binary, an alias for stellar-js (#1738).

Fixed

• AssembledTransaction.signAuthEntries() forwards a wallet's returned signerAddress to the default authorizer, so a classic-multisig signature made by a key other than the account being authorized is no longer rejected (#1681). A muxed M… signerAddress resolves to its base account; null or an empty string counts as omitted, and any other value that is not an account address is rejected by name. A custom authorizeEntry still receives raw bytes. A wallet that returns a signerAddress other than the key it signed with now fails with "signature doesn't match payload" instead of having the value ignored (#1744).
• AssembledTransaction.signAuthEntries() throws NoSignatureNeeded when it matched no auth entry, instead of returning as if it had signed (#1681, #1610). A custom authorizeEntry skips the pre-flight check that reports this for the default authorizer, so a wrong address was silent there. When address came from its publicKey default, the error says so. Every call that signs at least one entry is unaffected (#1743).
• authorizeEntry verifies a bare-Uint8Array signing callback against forAddress when one is given, rather than always against the entry's top-level credential address. A valid CAP-71 delegate signature was previously rejected with signature doesn't match payload (#1683, #1742). For every signer form, a forAddress that names no credential node is now rejected before the signer runs, rather than after.
• authorizeEntry throws a TypeError naming signatureScVal when the address it would verify against is a contract, instead of StrKey's invalid version byte (#1742).
• AssembledTransaction.needsNonInvokerSigningBy() walks CAP-71 delegate trees: it also lists the unsigned delegates under a contract account, even when the account itself has signed, and with includeAlreadySigned it lists every delegate under a contract account (#1655, #1747). signAuthEntries() still signs top-level addresses only, and names an unsigned delegate passed as address. sign() and signAndSend() now also reject an unsigned G… delegate under a contract account, whether or not the account has signed. This assumes every listed delegate must sign, so it can reject a transaction the network would accept when __check_auth uses only some of them. Pass ignoreContractDelegates to either method to skip that check for delegates under contract accounts; G… addresses are still checked.

New Contributors

• @​devtechedge made their first contribution in stellar/js-stellar-sdk#1725

Full Changelog: stellar/js-stellar-sdk@v17.1.0...v17.2.0

v17.1.0

v17.1.0

Added

• getClaimableBalanceIdFromResult(result, opIndex): reads the claimable balance ID created by a CreateClaimableBalance operation out of a submitted transaction's xdr.TransactionResult, unwrapping a fee bump when there is one. It returns the same 72-character hex form as Transaction.getClaimableBalanceId(opIndex), which derives the ID before submission; use this one when you only have the result. Horizon's result_xdr is base64, so decode it first with xdr.TransactionResult.fromXdr(result_xdr, "base64"), while rpc.Server.getTransaction already returns a parsed resultXdr. It throws a RangeError for an out-of-range opIndex, and a TypeError when result is not a transaction result, when the transaction failed, or when the operation at opIndex is not a successful CreateClaimableBalance (#1719).

Fixed

• Generated TypeScript bindings keep the raw spec name for a function parameter or struct field that is a reserved word or not a valid identifier, instead of renaming it: since #1345 a parameter new was typed as new_ while the runtime read new, so the typed call threw Missing field new, and a typed struct read of a renamed field was undefined. Methods and deploy now take a single args object, set(args: { new: number }, options?); call sites are unchanged, callers who used a renamed key switch to the raw name (new_ to new, _1st to args["1st"]), method names still get the trailing _, and a __constructor with no inputs now generates deploy(null, options) instead of deploy(options) (#1733).
• Horizon call builders now confine a resource identifier to one URL path segment, so a / in it no longer opens a new segment. An identifier that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint — accountId("") previously reached the collection endpoint and returned a page of records, and accountId([".."]) resolved to the server root. Affects accountId(), transaction(), operation(), offer(), claimableBalance(), ledger(), liquidityPoolId(), loadAccount() and the for*() neighbor filters; liquidityPoolId() was reachable the same way because its hex check is unanchored, which is tracked separately in #1703. A decimal number or bigint identifier still works, and well-formed identifiers are unaffected, since no valid Stellar identifier contains /, ., ? or # (#1702).
• These TypeErrors are thrown synchronously from call() and stream() rather than as a rejected promise, which matches the existing Too many filters specified error, so a caller that only attaches .catch() needs a try/catch. Three cases sit outside that, all unchanged by this release: loadAccount() is async, so it rejects and .catch() does work; liquidityPools().liquidityPoolId() throws from the builder method; and ledgers().ledger() with the forLedger() filters coerce the sequence with toString() first, so a nullish sequence throws there rather than reaching this guard (#1702).
• Templated Horizon _links functions now apply the call builders' path-segment guard to a path variable. One that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint: account.data({ key: ".." }) previously requested the account endpoint, not the data endpoint. Query values are unaffected. AccountResponse.data() and the server.root() links both take the path variable through an option TypeScript does not declare, so no call that compiles today changes behavior (#1718).
• StellarToml.Resolver.resolve() now validates the domain and throws Invalid domain before making a request (#1720). It previously put the string straight into the URL, so some inputs reached a different host, or a different path, than the caller named. A domain must be a plain host name with an optional port: credentials and an embedded /, ?, # or \ are rejected, as is an empty domain. Surrounding whitespace and a trailing / are stripped rather than rejected, so input that worked before keeps working. Host names, IP literals, IPv6 literals, and ports still work, but the request URL is normalized, so ACME.com is requested as acme.com.
• Asset.fromOperation preserves the assetTypeCreditAlphanum12 union arm even when the decoded code is four characters or shorter, instead of re-deriving the arm from code length. Such an asset now re-encodes to the same XDR bytes it was decoded from, and its getAssetType(), contractId(), equals(), and Asset.compare() results reflect the alphanum12 arm. equals() now also compares the asset type, so a decoded short-code alphanum12 asset is no longer equal to the alphanum4 asset with the same code and issuer. User-constructed assets are unaffected: new Asset(code, issuer) still derives the type from code length (#1584).
• rpc.Server.getContractData no longer reports a transport failure as a missing entry. It previously caught every error from the ledger lookup and rethrew { code: 404 }, so a 429, a 5xx, or a network error looked the same as an absent entry. Those errors now propagate untouched, and only a lookup that returns no entry throws the 404-shaped error, whose shape is unchanged (#1679).

Changed

• HorizonApi.Predicate gains the unconditional and abs_before_epoch fields it previously omitted, so the type now describes every predicate Horizon serves (#1701). It stays an interface, so declaration merging still works. One case does break at compile time: a consumer who already augmented the namespace to declare unconditional or abs_before_epoch with a different type than the SDK now uses gets TS2717 and must drop that part of their augmentation.
• Updated the production axios dependency from 1.18.0 to 1.20.0 (#1712).

New Contributors

• @​leocagli made their first contribution in stellar/js-stellar-sdk#1679
• @​yigitcangokmen made their first contribution in stellar/js-stellar-sdk#1670

... (truncated)

Changelog

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

v17.2.1

Fixed

• Asset.compare() orders two assets with the same code by their issuers' key bytes, as stellar-core does, instead of by the G… strkey text. The two orders can differ, so getLiquidityPoolId() and new LiquidityPoolAsset() rejected some valid asset pairs as out of order (#1766).
• scvSortedMap() and nativeToScVal() now sort map keys in the order the Soroban host requires: by ScVal type, then by value. They previously compared the keys' native string forms, so address, bytes, and mixed-type keys could come out in an order the host rejects. A plain object's keys are now sorted after conversion, so { 10: …, 9: … } with u32 keys becomes [9, 10]. Maps that mix key types change order: scvString keys now come before scvSymbol keys, whatever their names (#1766).

v17.2.0

Added

• A stellar-contract-bindings-typescript binary implementing the Stellar CLI plugin convention, reachable as stellar contract bindings typescript. It delegates to stellar-js generate. The package also adds a stellar-sdk binary, an alias for stellar-js (#1738).

Fixed

• AssembledTransaction.signAuthEntries() forwards a wallet's returned signerAddress to the default authorizer, so a classic-multisig signature made by a key other than the account being authorized is no longer rejected (#1681). A muxed M… signerAddress resolves to its base account; null or an empty string counts as omitted, and any other value that is not an account address is rejected by name. A custom authorizeEntry still receives raw bytes. A wallet that returns a signerAddress other than the key it signed with now fails with "signature doesn't match payload" instead of having the value ignored (#1744).
• AssembledTransaction.signAuthEntries() throws NoSignatureNeeded when it matched no auth entry, instead of returning as if it had signed (#1681, #1610). A custom authorizeEntry skips the pre-flight check that reports this for the default authorizer, so a wrong address was silent there. When address came from its publicKey default, the error says so. Every call that signs at least one entry is unaffected (#1743).
• authorizeEntry verifies a bare-Uint8Array signing callback against forAddress when one is given, rather than always against the entry's top-level credential address. A valid CAP-71 delegate signature was previously rejected with signature doesn't match payload (#1683, #1742). For every signer form, a forAddress that names no credential node is now rejected before the signer runs, rather than after.
• authorizeEntry throws a TypeError naming signatureScVal when the address it would verify against is a contract, instead of StrKey's invalid version byte (#1742).
• AssembledTransaction.needsNonInvokerSigningBy() walks CAP-71 delegate trees: it also lists the unsigned delegates under a contract account, even when the account itself has signed, and with includeAlreadySigned it lists every delegate under a contract account (#1655, #1747). signAuthEntries() still signs top-level addresses only, and names an unsigned delegate passed as address. sign() and signAndSend() now also reject an unsigned G… delegate under a contract account, whether or not the account has signed. This assumes every listed delegate must sign, so it can reject a transaction the network would accept when __check_auth uses only some of them. Pass ignoreContractDelegates to either method to skip that check for delegates under contract accounts; G… addresses are still checked.

v17.1.0

Changed

• HorizonApi.Predicate gains the unconditional and abs_before_epoch fields it previously omitted, so the type now describes every predicate Horizon serves (#1701). It stays an interface, so declaration merging still works. One case does break at compile time: a consumer who already augmented the namespace to declare unconditional or abs_before_epoch with a different type than the SDK now uses gets TS2717 and must drop that part of their augmentation.
• Updated the production axios dependency from 1.18.0 to 1.20.0 (#1712).

Added

• getClaimableBalanceIdFromResult(result, opIndex): reads the claimable balance ID created by a CreateClaimableBalance operation out of a submitted transaction's xdr.TransactionResult, unwrapping a fee bump when there is one. It returns the same 72-character hex form as Transaction.getClaimableBalanceId(opIndex), which derives the ID before submission; use this one when you only have the result. Horizon's result_xdr is base64, so decode it first with xdr.TransactionResult.fromXdr(result_xdr, "base64"), while rpc.Server.getTransaction already returns a parsed resultXdr. It throws a RangeError for an out-of-range opIndex, and a TypeError when result is not a transaction result, when the transaction failed, or when the operation at opIndex is not a successful CreateClaimableBalance (#1719).

Fixed

• Generated TypeScript bindings keep the raw spec name for a function parameter or struct field that is a reserved word or not a valid identifier, instead of renaming it: since #1345 a parameter new was typed as new_ while the runtime read new, so the typed call threw Missing field new, and a typed struct read of a renamed field was undefined. Methods and deploy now take a single args object, set(args: { new: number }, options?); call sites are unchanged, callers who used a renamed key switch to the raw name (new_ to new, _1st to args["1st"]), method names still get the trailing _, and a __constructor with no inputs now generates deploy(null, options) instead of deploy(options) (#1733).
• Horizon call builders now confine a resource identifier to one URL path segment, so a / in it no longer opens a new segment. An identifier that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint — accountId("") previously reached the collection endpoint and returned a page of records, and accountId([".."]) resolved to the server root. Affects accountId(), transaction(), operation(), offer(), claimableBalance(), ledger(), liquidityPoolId(), loadAccount() and the for*() neighbor filters; liquidityPoolId() was reachable the same way because its hex check is unanchored, which is tracked separately in #1703. A decimal number or bigint identifier still works, and well-formed identifiers are unaffected, since no valid Stellar identifier contains /, ., ? or # (#1702).
• These TypeErrors are thrown synchronously from call() and stream() rather than as a rejected promise, which matches the existing Too many filters specified error, so a caller that only attaches .catch() needs a try/catch. Three cases sit outside that, all unchanged by this release: loadAccount() is async, so it rejects and .catch() does work; liquidityPools().liquidityPoolId() throws from the builder method; and ledgers().ledger() with the forLedger() filters coerce the sequence with toString() first, so a nullish sequence throws there rather than reaching this guard (#1702).
• Templated Horizon _links functions now apply the call builders' path-segment guard to a path variable. One that is empty, ., .., or not a string/number/bigint throws a TypeError instead of re-pointing the request at a different endpoint: account.data({ key: ".." }) previously requested the account endpoint, not the data endpoint. Query values are unaffected. AccountResponse.data() and the server.root() links both take the path variable through an option TypeScript does not declare, so no call that compiles today changes behavior (#1718).
• StellarToml.Resolver.resolve() now validates the domain and throws Invalid domain before making a request (#1720). It previously put the string straight into the URL, so some inputs reached a different host, or a different path, than the caller named. A domain must be a plain host name with an optional port: credentials and an embedded /, ?, # or \ are rejected, as is an empty domain. Surrounding whitespace and a trailing / are stripped rather than rejected, so input that worked before keeps working. Host names, IP literals, IPv6 literals, and ports still work, but the request URL is normalized, so ACME.com is requested as acme.com.
• Asset.fromOperation preserves the assetTypeCreditAlphanum12 union arm even when the decoded code is four characters or shorter, instead of re-deriving the arm from code length. Such an asset now re-encodes to the same XDR bytes it was decoded from, and its getAssetType(), contractId(), equals(), and Asset.compare() results reflect the alphanum12 arm. equals() now also compares the asset type, so a decoded short-code alphanum12 asset is no longer equal to the alphanum4 asset with the same code and issuer. User-constructed assets are unaffected: new Asset(code, issuer) still derives the type from code length (#1584).
• rpc.Server.getContractData no longer reports a transport failure as a missing entry. It previously caught every error from the ledger lookup and rethrew { code: 404 }, so a 429, a 5xx, or a network error looked the same as an absent entry. Those errors now propagate untouched, and only a lookup that returns no entry throws the 404-shaped error, whose shape is unchanged (#1679).

v17.0.1

Added

• Every v16 XDR-acronym method spelling works again as a deprecated alias of its v17 name, easing migration. toXDR() / fromXDR() come back on xdr.* values (plus the static validateXDR()) and on Transaction / FeeBumpTransaction, TransactionBuilder, contract.AssembledTransaction, Claimant, and SorobanDataBuilder; toXDRObject() / fromXDRObject() come back on Asset (including toChangeTrustXDRObject() / toTrustLineXDRObject()), Memo, Operation, Claimant, MuxedAccount, LiquidityPoolAsset, and LiquidityPoolId. The aliases delegate to the v17 methods and keep their semantics: on xdr.* values, toXDR() returns a Uint8Array (not a Buffer) and fromXDR() requires a format for string input; the wrapper-class aliases behave as they did in v16. toXdrObject() / fromXdrObject() on xdr.* values are net-new methods with no legacy spelling, so they get no alias (#1690).

Fixed

• The type-generic xdr helpers — encodeArray, decodeArray, decodeStream and the fromXdr / validateXdr / fromJson statics — now throw a TypeError naming the helper and the argument when it has no static schema, such as an Int64/Uint32 shim or an abstract base (#1682). xdr.encodeArray(xdr.Uint32, [1]) previously threw TypeError: v.toXdrObject is not a function, and on an empty list returned a valid-looking 4-byte count. The four decode paths also name a missing static fromXdrObject, which only they need. Valid types are unaffected.
• xdr.Int32, xdr.Uint32, xdr.Int64 and xdr.Uint64 report their XDR type name from .name, instead of the internal "Shim" (#1682).
• BytesValue#toString() on the named byte aliases (Hash, Signature, AssetCode4, AssetCode12, PoolId, ContractId, …) now returns the class's declared encoding instead of base64 for every wrapper: new xdr.AssetCode4("KHL1").toString() is now "KHL1", was "S0hMMQ==". Use .toXdr("base64") for the wire form (#1689).

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).

... (truncated)

Commits

• b489349 chore(release): prepare v17.2.1 (#1767)
• c103c9b fix: order asset issuers and ScVal map keys the way the network does (#1766)
• 53435c3 docs: add release/support policy and security policy (#1729)
• 7cfd51a chore(release): prepare v17.2.0 (#1760)
• 40a8376 fix(contract): walk delegate trees in needsNonInvokerSigningBy (#1747)
• 284f4d1 docs(contract): explain what needsNonInvokerSigningBy can and cannot see (#1745)
• 791e4cf fix(contract): forward wallet signerAddress to default authorizer (#1744)
• a6ba91a fix(contract): report when signAuthEntries signs no auth entry (#1743)
• 7b6469e fix(auth): verify bare signature callbacks against forAddress (#1742)
• 74ac0c6 docs: regroup the Migration Guide and fix the guides-local race (#1740)
• Additional commits viewable in compare view

Install script changes

This version modifies prepare script that runs during installation. Review the package contents before updating.