chore(deps): bump the frontend-dependencies group across 1 directory with 19 updates

[dependabot]

Bumps the frontend-dependencies group with 19 updates in the /bimex-frontend directory:

Package	From	To
@sentry/react	10.68.0	10.71.0
@stellar/stellar-sdk	16.1.0	17.0.1
@supabase/supabase-js	2.110.9	2.112.4
i18next	26.3.6	26.4.0
lucide-react	1.27.0	1.34.0
react-i18next	17.0.11	17.0.12
@axe-core/react	4.12.1	4.13.0
@playwright/test	1.62.0	1.62.1
@testing-library/jest-dom	7.0.0	7.0.1
@testing-library/user-event	14.6.1	14.6.6
@types/react	19.2.17	19.2.18
@types/react-dom	19.2.3	19.2.5
@vitejs/plugin-react	6.0.4	6.1.0
@vitest/coverage-v8	4.1.10	4.1.11
eslint	10.8.0	10.9.1
eslint-plugin-react-refresh	0.5.3	0.5.4
globals	17.8.0	17.11.0
vite	8.1.5	8.2.2
vitest	4.1.10	4.1.11

Updates @sentry/react from 10.68.0 to 10.71.0

Release notes

Sourced from @​sentry/react's releases.

10.71.0

Important Changes

• feat(v10/core)!: Enable logs by default (#23311)

The enableLogs client option now defaults to true, so Sentry Logs work without any manual opt-in. Nothing is captured unless you call the Sentry.logger.* APIs or add a log-forwarding integration (such as consoleLoggingIntegration, pinoIntegration, or the winston transport), and you can set enableLogs: false to opt out. Although a default change like this would normally land in a major release, we are shipping it in a minor after careful consideration, since it sends no data on its own and only takes effect once you actively use the logging APIs or a logging integration.

Other Changes

• feat(v10/core): Deprecate scope.clear() method (#23231)
• fix(v10/core): Bound child span tracking on long-lived spans (#23406)
• fix(v10/core): Read Supabase PostgREST headers from Headers instances (#23241)
• fix(v10/hono): Use captureException from scope, not from Client (#23280)
• fix(v10/nuxt): Delete source maps after Nitro finishes building (#23508)
• fix(v10/react-router): Carry multi-byte UTF-8 across SSR stream chunk boundaries (#23421)
• fix(v10/react): Match TanStack Router pageload against the router location (#23494)

• test(v10/nextjs): Add e2e app for a user-owned OpenTelemetry setup (#23278)

Bundle size 📦

Path	Size
@​sentry/browser	27.1 KB
@​sentry/browser - with treeshaking flags	25.58 KB
@​sentry/browser (incl. Tracing)	45.51 KB
@​sentry/browser (incl. Tracing + Span Streaming)	47.25 KB
@​sentry/browser (incl. Tracing, Profiling)	50.15 KB
@​sentry/browser (incl. Tracing, Replay)	83.83 KB
@​sentry/browser (incl. Tracing, Replay) - with treeshaking flags	73.71 KB
@​sentry/browser (incl. Tracing, Replay with Canvas)	88.45 KB
@​sentry/browser (incl. Tracing, Replay, Feedback)	100.79 KB
@​sentry/browser (incl. Feedback)	43.87 KB
@​sentry/browser (incl. sendFeedback)	31.78 KB
@​sentry/browser (incl. FeedbackAsync)	36.79 KB
@​sentry/browser (incl. Metrics)	28.16 KB
@​sentry/browser (incl. Logs)	28.38 KB
@​sentry/browser (incl. Metrics & Logs)	29.06 KB
@​sentry/react	28.86 KB
@​sentry/react (incl. Tracing)	47.72 KB
@​sentry/vue	32.4 KB
@​sentry/vue (incl. Tracing)	47.43 KB
@​sentry/svelte	27.12 KB
CDN Bundle	29.43 KB
CDN Bundle (incl. Tracing)	47.43 KB

... (truncated)

Changelog

Sourced from @​sentry/react's changelog.

10.71.0

Important Changes

• feat(v10/core)!: Enable logs by default (#23311)

The enableLogs client option now defaults to true, so Sentry Logs work without any manual opt-in. Nothing is captured unless you call the Sentry.logger.* APIs or add a log-forwarding integration (such as consoleLoggingIntegration, pinoIntegration, or the winston transport), and you can set enableLogs: false to opt out. Although a default change like this would normally land in a major release, we are shipping it in a minor after careful consideration, since it sends no data on its own and only takes effect once you actively use the logging APIs or a logging integration.

Other Changes

• feat(v10/core): Deprecate scope.clear() method (#23231)
• fix(v10/core): Bound child span tracking on long-lived spans (#23406)
• fix(v10/core): Read Supabase PostgREST headers from Headers instances (#23241)
• fix(v10/hono): Use captureException from scope, not from Client (#23280)
• fix(v10/nuxt): Delete source maps after Nitro finishes building (#23508)
• fix(v10/react-router): Carry multi-byte UTF-8 across SSR stream chunk boundaries (#23421)
• fix(v10/react): Match TanStack Router pageload against the router location (#23494)

• test(v10/nextjs): Add e2e app for a user-owned OpenTelemetry setup (#23278)

10.70.0

• feat(v10/core): Support stable MCP SDK v2 (#22986)
• feat(v10/deps): Bump @sentry/node-cpu-profiler to 2.4.3 (#22992)
• feat(v10/solid,solidstart): Support @solidjs/router v1 (#23163)
• fix(v10/cloudflare): Fork the isolation scope for Durable Object methods (#23189)
• fix(v10/cloudflare): Get original waituntil in workflows (#23192)
• fix(v10/cloudflare): Instrument DO RPC methods on the prototype, not a Proxy (#23190)
• fix(v10/cloudflare): Set agent conversation id on the onRequest path (#22985)
• fix(v10/cloudflare): Set conversation id independent of session name (#23193)
• fix(v10/cloudflare): Try/catch on non-configurable prototypes (#23191)
• fix(v10/cloudflare): Use gen_ai.agent.name for class names (#22987)
• fix(v10/core,browser): Handle errors from other realms (#23201)
• fix(v10/core): Sample errors after beforeSend while preserving session updates (#22819)
• fix(v10/hono): Include originalException in captured exception hint (#22990)
• fix(v10/nextjs): meriyah issue for standalone build (#23055)
• fix(v10/nextjs): Remove tracing from middleware wrappers (#22904)
• fix(v10/profiling-node): Respect profileSessionSampleRate in trace profile lifecycle (#22940)
• fix(v10/react-router): Preserve sourcemaps.disable when unstable_sentryVitePluginOptions is set (#22966)
• fix(v10/react): Remove routes from shared set on <Routes> unmount (#22948)
• fix(v10/sveltekit): Export metrics from worker entry point (#23027)

... (truncated)

Commits

• 9fcb063 release: 10.71.0
• fbc14d8 meta(changelog): Update changelog for 10.71.0 (#23517)
• 671f4b1 fix(v10/nuxt): Delete source maps after Nitro finishes building (#23508)
• 0211227 fix(v10/react): Match TanStack Router pageload against the router location (#...
• bbea828 feat(v10/core)!: Enable logs by default (#23311)
• 7ded310 fix(v10/core): Bound child span tracking on long-lived spans (#23406)
• 245d807 fix(v10/react-router): Carry multi-byte UTF-8 across SSR stream chunk boundar...
• 1d439a3 fix(v10/core): Read Supabase PostgREST headers from Headers instances (#23241)
• 8f03efe test(v10/nextjs): Add e2e app for a user-owned OpenTelemetry setup (#23278)
• c884ae1 fix(v10/hono): Use captureException from scope, not from Client (#23280)
• Additional commits viewable in compare view

Updates @stellar/stellar-sdk from 16.1.0 to 17.0.1

Release notes

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

v17.0.1

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

Full Changelog: stellar/js-stellar-sdk@v17.0.0...v17.0.1

v17.0.0: Protocol 28

v17.0.0: Protocol 28

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

... (truncated)

Changelog

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

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

• 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

... (truncated)

Commits

• 74ac883 chore(release): prepare v17.0.1 (#1691)
• 301d89f fix(xdr): throw on an unusable type argument at the call site (#1682)
• 88b10e1 feat: restore v16 XDR method spellings as deprecated aliases (#1690)
• 3793b7a fix(xdr): honor declared encoding in byte wrappers' toString() (#1689)
• 2b59682 Document Deno usage (#1677)
• 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)
• Additional commits viewable in compare view

Updates @supabase/supabase-js from 2.110.9 to 2.112.4

Release notes

Sourced from @​supabase/supabase-js's releases.

v2.112.4

2.112.4 (2026-08-24)

🩹 Fixes

• auth: convert stolen-lock AbortError when acquireTimeout is 0 (#2616)
• auth: warn on deprecated lock option and prevent unhandled refresh rejection (#2627)
• postgrest: move override fixtures out of generated types, repair codegen (#2605)
• realtime: respect custom logger for send() REST fallback warning (#2612)

❤️ Thank You

• Katerina Skroumpelou @​mandarini
• mmustafasenoglu @​mmustafasenoglu

v2.112.4-canary.3

2.112.4-canary.3 (2026-08-24)

🩹 Fixes

• auth: warn on deprecated lock option and prevent unhandled refresh rejection (#2627)

❤️ Thank You

• Katerina Skroumpelou @​mandarini

v2.112.4-canary.2

2.112.4-canary.2 (2026-08-24)

🩹 Fixes

• auth: convert stolen-lock AbortError when acquireTimeout is 0 (#2616)
• realtime: respect custom logger for send() REST fallback warning (#2612)

❤️ Thank You

• Katerina Skroumpelou @​mandarini
• mmustafasenoglu @​mmustafasenoglu

v2.112.4-canary.1

2.112.4-canary.1 (2026-08-12)

This was a version bump only, there were no code changes.

v2.112.4-canary.0

2.112.4-canary.0 (2026-08-11)

🩹 Fixes

• postgrest: move override fixtures out of generated types, repair codegen (#2605)

... (truncated)

Changelog

Sourced from @​supabase/supabase-js's changelog.

2.112.4 (2026-08-24)

This was a version bump only for @​supabase/supabase-js to align it with other projects, there were no code changes.

2.112.3 (2026-08-11)

🩹 Fixes

• supabase: improve trace propagation sampling and diagnostics (#2604)
• supabase: add trace context headers to canonical CORS allow-list (#2603)

❤️ Thank You

• Katerina Skroumpelou @​mandarini

2.112.2 (2026-08-06)

This was a version bump only for @​supabase/supabase-js to align it with other projects, there were no code changes.

2.112.1 (2026-08-05)

🩹 Fixes

• realtime: ensure setAuth doesn't disable token refresh (#2592)

❤️ Thank You

• Eduardo Gurgel

2.112.0 (2026-08-03)

🚀 Features

• supabase: move Ope...

  Description has been truncated

[dependabot]

Labels

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

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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
bimex-frontend	Error		Aug 29, 2026 1:07am

[David1984TK]

Revisé el log de "Frontend React" en este PR (el bump grande de 19 paquetes, sucesor de #313): sigue fallando con exactamente las mismas 5 vulnerabilidades sin resolver (ajv, brace-expansion, fast-uri, minimatch, nanoid — mismos GHSA IDs de siempre). Ya es el segundo bump de dependabot seguido que no logra tocar estas dependencias transitivas — confirma que esto no se arregla con más bumps, hace falta el overrides manual en package.json (o documentarlas en ALLOWED_ADVISORIES con un issue de seguimiento) que ya sugiere scripts/check-audit.mjs.

Todo lo demás (Indexer Node.js, Contrato Soroban, CodeQL, Gitleaks, E2E) sale verde. El bump en sí es válido y no rompe nada — solo no resuelve lo que dice atacar. Se puede mergear igual como mejora de versiones si quieres, sabiendo que el audit gate se queda igual.

---

Generated by Claude Code