js-stellar-sdk
js-stellar-sdk copied to clipboard
optional simulate & wallet, editable TransactionBuilder
-
Remove
TimeoutInfinite, instead allowing people to set atimeoutInSecondswhen they initialize anAssembledTransaction. Default: 10. -
No more
walletparameter. Instead, you pass:-
publicKey– Will be used to construct theAccountobject that is used as the source of the transaction. Can be undefined, which means the null account will be used. Can be a string or, to ease operation with Freighter and other async-key-lookup in browser wallets, a promise of a string. -
signTransaction: matches thesignTransactionsignature from Freighter. Can be left blank when you initialize the ContractClient and only provided at the time that you callsignAndSend({ signTransaction: (...) => { ... } }) -
signAuthEntry: matches thesignAuthEntrysignature from Freighter. Can also be left initially blank, but is needed if/when you callsignAuthEntries.
-
-
You can now pass
simulate: falsewhen first creating your transaction to skip simulation. You can then modify the transaction using the TransactionBuilder attx.rawbefore manually callingsimulate. Example:const tx = await myContract.myMethod( { args: 'for', my: 'method', ... }, { simulate: false } ); tx.raw.addMemo(Memo.text('Nice memo, friend!')) await tx.simulate(); -
Make
.simulationgetter public -
Error types are now collected under
AssembledTransaction.ErrorsandSentTransaction.Errors. -
Move
ContractClient,AssembledTransactionto separate entrypoints, so that they are not included in the global API or bundle size, but can still be packaged together with all the related stellar-sdk logic. -
Export
ExampleNodeWalletfrom its own entrypoint, rather than hiding this logic entirely in the tests. @kalepail found this useful enough that he thought it would be worth exporting so other people can use it in their Node apps.
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎
To accept the risk, merge this PR and you will not be notified again.
| Alert | Package | Note | Source |
|---|---|---|---|
| Non OSI license | npm/[email protected] |
|
Next steps
What is a non OSI license?
(Experimental) Package has a non-OSI-approved license.
Consider the terms of the license for your given use case.
Take a deeper look at the dependency
Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.
Remove the package
If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.
Mark a package as acceptable risk
To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of ecosystem/package-name@version specifiers. e.g. @SocketSecurity ignore npm/[email protected] or ignore all packages with @SocketSecurity ignore-all
@SocketSecurity ignore npm/[email protected]
@Shaptic I still don't have write access to this repository—could you merge if you approve? @kalepail you might also be able to merge?
I don't feel comfortable merging as I'm not reviewing code as much as functionality. I'll leave that for @Shaptic
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@babel/[email protected], npm/@babel/[email protected], npm/@babel/[email protected], npm/@babel/[email protected], npm/@babel/[email protected], npm/@babel/[email protected], npm/@babel/[email protected], npm/@definitelytyped/[email protected], npm/@jridgewell/[email protected], npm/@stellar/[email protected], npm/@types/[email protected], npm/@types/[email protected], npm/@typescript-eslint/[email protected], npm/@typescript-eslint/[email protected], npm/@typescript-eslint/[email protected], npm/@typescript-eslint/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected], npm/[email protected]
@chadoh lmk if you'd rather I merge this and you resolve feedback in a later PR! doesn't matter to me
@Shaptic ok, I addressed all your feedback here. I think this is ready to merge to bindings. I'll then open a PR from bindings back to master—I think it's probably good enough to get it merged! I really want to remove the stale logic that's hard-coded into TS Bindings and rely on this instead.
Thanks, @Shaptic! You'll have to merge, as I do not have permission.