Read about what's new in the latest version of Stacks.js.
This version comes with a lot of improvements and new features, but it also adds some breaking changes.
Want to use these latest features? Install packages using the latest tag:
Many Stacks.js representations we're not debuggable for developers.
Logging Clarity values resulted in unintelligible type and value numbers, confusing even experienced Stacks developers.
Private keys were also included unnecessary type properties with raw byte arrays.
"Magic" numbers are all accross the codebase (as they are needed for serialization), but these shouldn't be part of the "public" interfaces.
For a long time, Stacks.js "network" instances were used for "networking" and "network" definitions.
This caused confusion, as most users use mainnet or testnet for most of their interactions.
The "networking" (aka fetching) logic is now more clearly customizable.
From now on "network" objects are static (aka constants) and don't require instantiation.
These changes should make it more obvious when functions are using network object properties vs when they are doing actual networking.
In most cases, developers shouldn't need the @stacks/network package anymore.
The network parameter can be used with string literals: 'mainnet', 'testnet', 'devnet', 'mocknet'.
import{ StacksTestnet }from'@stacks/network';
makeSTXTokenTransfer({
-
network:newStacksTestnet(),
+
network:'testnet'
// ...
});
Stacks Network client
In case a function also takes a client parameter, it will be doing actual networking.
This way you can use string literal networks with a custom node.
You can also still use network objects with the client parameter as part of the network object.
The client parameter can be any object-like structure containing a baseUrl and fetch property.
The baseUrl property should be a string containing the base URL of the Stacks node you want to use.
Where possible, Stacks.js now offers function to translate between different representations and concepts.
The naming is consistent across the board and uses A To B naming.
For example, if we have a private key and want to get the address, we can use the privateKeyToAddress function.
To make it easier to discover all fetching functions, they now all start with fetch.
The following methods were renamed:
estimateFee → fetchFeeEstimate
estimateTransfer → fetchFeeEstimateTransfer
estimateTransaction → fetchFeeEstimateTransaction
getAbi → fetchAbi
getNonce → fetchNonce
getContractMapEntry → fetchContractMapEntry
callReadOnlyFunction → fetchCallReadOnlyFunction
broadcastTransaction wasn't renamed to highlight the uniqueness of the method.
Namely, the node/API it is sent to will "broadcast" the transaction to the mempool and is more of an irreversible action.
The ClarityType enum was replaced by a more readable version.
The previous (wire format compatible) enum is still available as ClarityWireType.
These types are considered somewhat internal and shouldn't cause breaking changes for most use-cases.
The property holding the value of the data type is now called value in all cases.
Previously, there was a mix of value, list, buffer etc.
For bigint values, the type of the value property is a now string, for better serialization compatibility.
Support for encrypting/decrypting mnemonics with triplesec was removed.
This impacts the methods: decrypt, decryptMnemonic, and decryptLegacy.
Make sure to update your code to if mnemonics are stored somewhere encrypted using the legacy method.
Renamed internals to avoid confusion between "message" and wire-format for serialization.
This is only used for advanced serialization use-cases internally and should not be needed for most users.
The intToBigInt method no longer supports two's complement signed integers and removed the signed boolean parameter.
This likely was a misunderstood and unused feature.