cosmjs
cosmjs copied to clipboard
cosmos
migrate to @scure/base for base64 & bech32 encoding
TypeScript return types are narrowed in a way that's still backwards-compatible.
This repository exceeded its LFS budget. The account responsible for the budget should increase it to restore access.
CircleCI output
Cloning git repository - [email protected]:cosmos/cosmjs.git
Fetching from remote repository
Checking out branch
Cloning into '.'...
From github.com:cosmos/cosmjs
* [new ref] refs/pull/1666/head -> origin/pull/1666
Downloading .yarn/cache/@agoric-babel-standalone-npm-7.9.5-d7c88bfb35-d5bae2402a.zip (4.6 MB)
Error downloading object: .yarn/cache/@agoric-babel-standalone-npm-7.9.5-d7c88bfb35-d5bae2402a.zip (3b2b29e): Smudge error: Error downloading .yarn/cache/@agoric-babel-standalone-npm-7.9.5-d7c88bfb35-d5bae2402a.zip (3b2b29e1a7e1b6f059ef1c4c2429defd1bbb9fb7187b7c63c5f243caf13fb5f7): batch response: This repository exceeded its LFS budget. The account responsible for the budget should increase it to restore access.
Errors logged to '/home/circleci/project/.git/lfs/logs/20250612T163655.63273083.log'.
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: .yarn/cache/@agoric-babel-standalone-npm-7.9.5-d7c88bfb35-d5bae2402a.zip: smudge filter lfs failed
failed to checkout: exit status 128
Thanks. LFS budget was fixed now.
I am happy for the new implementation. But can we do that without changing the types of CosmJS interfaces? Is it possible to use bech32 decoding without knowing the prefix?
But can we do that without changing the types of CosmJS interfaces? Is it possible to use bech32 decoding without knowing the prefix?
For a backwards compatible 0.33.2 release, existing TypeScript code can't break if it was expecting a string to be returned from the encoding function, and a more-specific-kind-of-string gets returned now, right? I tested it out. Things only break if you change the types of a function's arguments to be more-specific and strict than the caller provides.
The new return type of the decode function and some address-getters doesn't force users to change anything, but it does give them the choice to take advantage of the new type to enforce more compile-time constraints (statically ensuring this string is a valid address) in their codebase.
And if you mean, is it possible to use this library's decode function without casting (address as `${string}1${string}`), it really does require that.
I am trying to use @scure/base without changing public interfaces. But hitting some issues. See https://github.com/paulmillr/scure-base/issues/43
If no breaking type interface changes ever happen in CosmJS, why are there so many semver-incompatible versions (0.33, 0.34, 0.35), which indicate breaking changes?
There are breaking changes in public APIs every now and then and if they improve the user experience I am happy to do them. But I don't want to make unnecessary changes that require users to rewrite half of their app just to get an overly strict type into functionality that every user is perfectly happy with.
I think this is the API we are missing: https://github.com/paulmillr/scure-base/pull/45
I split this work into https://github.com/cosmos/cosmjs/pull/1825 and https://github.com/cosmos/cosmjs/issues/1826. Thank you for pushing this foreward