Skip to content

Releases: stellar/js-soroban-client

v1.0.1

03 Jan 18:22
3791309
Compare
Choose a tag to compare

Warning: This library is no longer being maintained, in favor of the @stellar/stellar-sdk package. Please read the migration guide for how to upgrade to that package. Future changes will only be made there.

This release merely correctly marks the package as deprecated.

v1.0.0

08 Dec 00:35
cbf1542
Compare
Choose a tag to compare

Warning: This library is no longer being maintained, in favor of the @stellar/stellar-sdk package. Please read the migration guide for how to upgrade to that package. Future changes will only be made there.

v1.0.0: Protocol 20, Soroban!

This is the stable Protocol 20 release. The following is a list of changes since the previous beta:

Breaking Changes

  • See the new deprecation warning at the top of this document and in the README.
  • XDR has been upgraded to the latest stellar-base release, supporting the current stable XDR for Protocol 20 (#167).

Fixed

  • The Server.getEvents method now correctly parses responses without a contractId field set: the events[i].contractId field on an event will be omitted if there was no ID in the event (e.g. for system events; (#172)).
  • The Server.getEvents() method will correctly parse the event value as an xdr.ScVal rather than an xdr.DiagnosticEvent (#172).
  • The Server.getEvents() method will correctly set startLedger to be a number rather than a string (#174).

Full Changelog: v0.11.2...v1.0.0

v1.0.0-beta.4

03 Nov 19:42
abc79fc
Compare
Choose a tag to compare

Note: This version is currently only compatible with Stellar networks running the Protocol 20 release candidate such as the current Testnet and Futurenet (using stellar/stellar-xdr@9ac0264).

This is a patch release: please refer to v1.0.0-beta.0 or the link below for a complete changelog.

v1.0.0-beta.4

Fixed

  • The stellar-base dependency has been upgraded to v10.0.0-beta.4 which fixes a bug with large sequence numbers (#170).

Full Changelog: v0.11.2...v1.0.0-beta.4

v1.0.0-beta.3

13 Oct 17:53
96238c2
Compare
Choose a tag to compare

Note: This version is currently only compatible with Stellar networks running the Protocol 20 release candidate such as the current Testnet (using stellar/stellar-xdr@9ac0264).

This is a patch release: please refer to v1.0.0-beta.0 for a complete changelog.

v1.0.0-beta.3

Added

  • Responses for Server.getContractData and Server.getLedgerEntries now include an expirationLedgerSeq attribute on ledger data entries that have expiry information (#153).
  • The new Server._simulateTransaction method will return the raw response directly from the RPC server rather than parsing XDR fields (#160).

Breaking Changes

  • The stellar-base dependency has been upgraded to v10.0.0-beta.3 which contains breaking changes related to auth helpers and some bugfixes (#158).
  • All endpoints will now automatically decode XDR structures whenever possible. In particular,
    • For the Server.getLedgerEntries response (#154), we parse:
      • entries is now guaranteed to exist, but it may be empty
      • entries[i].key is an instance of xdr.LedgerKey
      • the entries[i].xdr field is now val, instead
      • entries[i].val is an instance of xdr.LedgerEntryData
    • For the Server.sendTransaction response (#157), we parse:
      • errorResultXdr is renamed to errorResult
      • If it's present, it's an instance of xdr.TransactionResult
    • For the Server.getEvents response (#156), we parse:
      • events[i].contractId is now an instance of Contract
      • events[i].topic is now a list of decoded xdr.ScVal instances
      • events[i].value.xdr is now remapped directly to events.value
      • events[i].value is a decoded xdr.ScVal instance
    • For the Server.sendTransaction response (#157), we parse:
      • errorResultXdr is now errorResult, a parsed instance of xdr.TransactionResult
  • If you want to continue to use the raw RPC responses, you can use the _-prefixed methods which will return the response directly:
    • Server._getLedgerEntries
    • Server._sendTransaction
    • Server._getEvents
    • Server._simulateTransaction
    • Server._getTransaction

Full Changelog: v0.11.2...v1.0.0-beta.3

v1.0.0-beta.2

14 Sep 19:52
d571abc
Compare
Choose a tag to compare

Note: This version is currently only compatible with Stellar networks running the Protocol 20 release candidate such as the current Testnet (using stellar/stellar-xdr@9ac0264).

This is a patch release: please refer to v1.0.0-beta.0 for a complete changelog.

Fixed

  • The variations of responses from simulateTransaction were not always being parsed correctly (#146).

Full Changelog: v0.11.2...v1.0.0-beta.2

v1.0.0-beta.1

13 Sep 23:45
828440f
Compare
Choose a tag to compare

Note: This version is currently only compatible with Stellar networks running the Protocol 20 release candidate such as the current Testnet (using stellar/stellar-xdr@9ac0264).

This is a patch release: please refer to v1.0.0-beta.0 for a complete changelog.

Fixes

  • stellar-base has been upgraded to v10.0.0-beta.1 which includes important bugfixes (#145).

Full Changelog: v0.11.2...v1.0.0-beta.1

v1.0.0-beta.0

13 Sep 18:06
00f3d10
Compare
Choose a tag to compare

Note: This version is currently only compatible with Stellar networks running the Protocol 20 release candidate such as the current Testnet (using stellar/stellar-xdr@9ac0264).

v1.0.0-beta.0: Protocol 20

Added

  • SorobanRpc.isSimulationSuccess, SorobanRpc.isSimulationRestore and SorobanRpc.isSimulationError are helper methods to differentiate the various responses when simulating a transaction (#132).

Breaking Changes

  • The XDR has been upgraded to the final testnet version via the stellar-base dependency (v10.0.0-beta.0, #135).
  • The simulateTransaction endpoint will now return a restorePreamble structure containing the recommended footprint and minimum resource fee for a transaction with a Operation.restoreFootprint which would have made the simulation succeed (#132).
  • It also parses and transforms the raw schema into something easier to access:
    • results?[] is coalesced into a single result?
    • results[i].xdr is now result.retval
    • every XDR object is decoded when possible, e.g. result.retval is an xdr.ScVal
    • events?[] now always exists (but may be empty)

Fixed

  • Result types are now handled correctly by ContractSpec (#138).

Full Changelog: v0.11.2...v1.0.0-beta.0

v0.11.2

01 Sep 22:19
62fe76d
Compare
Choose a tag to compare

Note: This is likely to be the last release compatible with Preview 10.

Fixed

  • The stellar-base dependency has been updated to v10.0.0-soroban.8, fixing some bugs and adding some small things. Refer to its release notes (stellar/js-stellar-base#687) for details.

v0.11.1

24 Aug 17:53
684f1b3
Compare
Choose a tag to compare

Fixed

  • This adds sensible defaults Server.simulateTransaction's response when the RPC server omits certain fields in an unexpected way (#131).

Full Changelog: v0.11.0...v0.11.1

v0.11.0

21 Aug 18:42
377e3fe
Compare
Choose a tag to compare

v0.11.0

Fixed

  • The SimulateTransactionResponse's error field now has the correct type (that is, string: #123).
  • Many irrelevant or unused dependencies have been eliminated (such as eventsource, lodash, and others), lowering overall bundle size (#126).

Added

  • A new ContractSpec class to facilitate building native JavaScript structures from custom contract types. Given a specification for the data structure (i.e. xdr.ScSpecEntry[]), it will interpret the values via the specified type (#115).

Breaking Changes

  • The minimum supported NodeJS version is now Node 16.
  • Server.prepareTransaction now returns a TransactionBuilder instance rather than an immutable Transaction, in order to facilitate modifying your transaction after assembling it alongside the simulation response (#127).
    • The intent is to avoid cloning the transaction again (via TransactionBuilder.cloneFrom) if you need to modify parameters such as the storage access footprint.
    • To migrate your code, just call .build() on the return value.
  • The RPC response schemas for simulation (see Server.simulateTransaction()) have been upgraded to parse the base64-encoded XDR automatically. The full interface changes are in the pull request (#127), but succinctly:
    • SimulateTransactionResponse -> RawSimulateTransactionResponse
    • SimulateHostFunctionResult -> RawSimulateHostFunctionResult
    • Now, SimulateTransactionResponse and SimulateHostFunctionResult include the full, decoded XDR structures instead of raw, base64-encoded strings for the relevant fields (e.g. SimulateTransactionResponse.transactionData is now an instance of SorobanDataBuilder, events is now an xdr.DiagnosticEvent[] [try out humanizeEvents for a friendlier representation of this field]).
    • The SimulateTransactionResponse.results[] field has been moved to SimulateTransactionResponse.result?, since there will always be exactly zero or one result.
  • The GetTransactionStatus is now an enum with actual values rather than a type (#129).
  • The RPC response schemas for retrieving transaction details (Server.getTransaction()) have been upgraded to parse the base64-encoded XDR automatically. The full interface changes are in the pull request (#129), but succinctly:
    • GetTransactionResponse -> RawGetTransactionResponse
    • GetTransactionResponse is now one of GetSuccessfulTransactionResponse | GetFailedTransactionResponse | GetMissingTransactionResponse, which gives proper typing to the interface depending on the response's status field.
    • All of the *Xdr properties are now full, decoded XDR structures.
    • There is a new returnValue field which is a decoded xdr.ScVal, present iff the transaction was a successful Soroban function invocation.

Not all schemas have been broken in this manner in order to facilitate user feedback on this approach. Please add your 👍 or 👎 to #128 to vote on whether or not we should do this for the other response schemas.

Full Changelog: v0.10.1...v0.11.0