keep-starknet-strange / abi-wan-kanabi Goto Github PK

Today, tests are rather examples than proper tests.
This issue proposes to write actual tests, some with failing typechecks, others that typecheck.
Tests should be included in package.json so that they can be run with the following command:

npm run test

https://github.com/haroune-mohammedi/abi-wan-kanabi/blob/rebase-contract-functions/

Cairo 1 has introduced a new type system.
In particular, the corelibs have the following native types that should be supported by abiwan:

• felt252
• bool
• integers
• strings // there is no string in cairo

It seems like typescript maintainers are going down unreasonable paths: microsoft/TypeScript#41883

This means any ts files shipped in this module are checked against tsconfig of the clients. There are some unused variables and imported but not used parameters. If possible, please strip the index.ts file from the published package

Starknet.js is on version 5, abi-wan-kanabi should match the version there.

FYI - I wanted to contribute, but tests are currently failing on main, and I felt uncomfortable contributing at this state.

Tests examples have been compiled with Cairo 1.0 but are already outdated.
For example core::felt has moved to core::felt252.

Tests should be up to date with latest Cairo 1 ABIs.
In order to make it easier to bring them up to date, tests should include simple cairo contracts.
These contracts are then compiled to their abi.json files.

Note that we do not wish tests to depend on cairo compiler, but only to record the contracts that generated the ABIs.
This task might require to modify the actual tests today and their ABI in favour of simpler ones if needed.
However, test cases will have to be expanded, and that's another issue

This issue is about all the little changes we have to make to integrate abiwan to starknet.js

The first thing I tired is to reproduce the same cairo1 test with typed contract instead of regular contract and here's all the TypeScript complains I got:

TL;DR

• meta-class functions are expected to accept callData

• meta-class functions are expected to return the transaction

• felt252 is expected to accept string, number and Uint256

• tuples are expected to accept Record

• u256 is expected to accept Uint256

• ContractAddress is expected to accept string

All Errors

const tx = await cairo1Contract.increase_balance(
    CallData.compile({
        amount: 100,
    })
);

await account.waitForTransaction(tx.transaction_hash);

• Argument of type 'Calldata' is not assignable to parameter of type 'bigint'.ts(2345)
• Property 'transaction_hash' does not exist on type 'void'.ts(2339)

const balance = await cairo1Contract.get_balance({
    parseResponse: false,
});

• Expected 0 arguments, but got 1.ts(2554)

const result1 = await cairo1Contract.test_u256(uint256(2n ** 256n - 2n));

• Argument of type 'Uint256' is not assignable to parameter of type 'bigint'.ts(2345)

const tx = await cairo1Contract.set_ca('123');

• Argument of type 'string' is not assignable to parameter of type 'bigint'.ts(2345)

let tx = await cairo1Contract.increase_balance(100);

• Argument of type 'number' is not assignable to parameter of type 'bigint'.ts(2345)

const status = await cairo1Contract.echo_un_tuple(tuple(77, 123));

• Argument of type 'Record<number, boolean | object | BigNumberish>' is not assignable to parameter of type '[bigint, number | bigint]'.ts(2345)

const status1 = await cairo1Contract.echo_array_u256([123, 55, 77, 255]);

• Type 'number' is not assignable to type 'bigint'.ts(2322)

const status11 = await cairo1Contract.echo_array_u256([
    uint256(123),
    uint256(55),
    uint256(77),
    uint256(255),
]);

• Type 'Uint256' is not assignable to type 'bigint'.ts(2322)

const status = await cairo1Contract.get_bet(1, {
    formatResponse: { name: 'string', description: 'string' },
});

• Expected 1 arguments, but got 2.ts(2554)

The FunctionRet type returns the value directly, for example:

const balanceOf = erc20.balanceOf(123);

balanceOf type is:

{
    low: number;
    high: number;
}

But in reality it's

{
   balance: {
       low: number;
       high: number;
   }
}

right?

I can open a PR for this.

https://github.com/keep-starknet-strange/abi-wan-kanabi/actions/runs/6666211028

It would be useful to export a function to actually create contract instances with the ABI based types. This could then be used in the starknet.js and starknet-react libs, providing better type support there. This is what happens when using wagmi, for example.

The usage could be something like:

const contract = getContract(abi, address, account);

const bal = await contract.balanceOf... <-- IDE autocomplete, args validation, and typed return value

Does this make sense? I could open a PR for this feature.

The types inferred for enums is not exactly what we want, check the example below

ABI:

{
    "type": "enum",
    "name": "example::TestEnum",
    "variants": [
      {
        "name": "int128",
        "type": "core::integer::u128"
      },
      {
        "name": "felt",
        "type": "core::felt252"
      },
      {
        "name": "tuple",
        "type": "(core::integer::u32, core::integer::u32)"
      }
    ]
  }

Test:

assertType<StringToPrimitiveType<TAbi, 'example::TestEnum'>>({
  int128: intValue,
  felt: bigIntValue,
  tuple: [intValue, bigIntValue]
})

Support for tuples.
Should need some max_depth configuration to control the amount of nesting supported.

Cairo official documentation on tuples (as of writing, only a placeholder section):
https://www.cairo-lang.org/docs/v1.0/language_constructs/tuple-types.html

While trying to make abiwan fully compatible with starknet.js as per starknet-io/starknet.js#877, I started by running the tests in ./__tests__/cairo1_typed.test.ts and discovered the order of options argument is not the same as starknet.js

The goal of this issue is simply to fix that, even though the goal is simple it doens't mean the solution is simple ! Will see!

The goal of this issue is to make sure Abiwan is fully compatible with the latest starknet.js versions, basically make sure it supports all the newly added types, for instance:

• core::starknet::secp256k1::Secp256k1Point
• u512

@PhilippeR26 You're welcome to add types I missed in this issue

Projects management: issues, documentation, meetings

Trying to build a Vite site that uses a package (@dynamic-labs/ethereum), which uses this one. Build fails with error related to abi-wan-kanabi.
See this issue:
dynamic-labs/react-18-vite-typescript#3

Currently, to be able to use abiwan, one has to generate a typescript file from the contracts abi json file.
This is a limitation due to typescript's inability to import a json narrowly.
There is actually a simple bash script that copied the abi from the json to ts that worked for Cairo 0.10.

In this issue, we would like to setup the abi object in typescript like it is done in Wagmi's cli:
https://wagmi.sh/cli#run-code-generation

This would look something like this:

npx abiwan generate

It should now support Cairo 1.0 contract's ABIs, removing the unnecessary parts such as the sierra-code from it.

We can use starknet.js's issue as a reference: starknet-io/starknet.js#886

It seems like the only added types are bytes31 and ByteArray

https://www.cairo-lang.org/docs/reference/syntax.html#syntax-structs
Current implementation support flat Tuples, but struct and tuples can nest in each other.

Implementation of Arrays types

Official documentation (as of writing, only a placeholder):
https://www.cairo-lang.org/docs/v1.0/language_constructs/array-types.html

Currently, function parameters require to be inside the array

const [balance] = call(ABI, 'balanceOf', [123]);

the expectation is to be flat data

const [balance] = call(ABI, 'balanceOf', 123);

Resolve the return type so it doesn't require an array
current implementation:
const [balance] = call(...
expected implementation:
const balance = call(

This issue is about being able to support generic types such as Option.
For example, Option should correspond to Option on typescript side.
Firstly, one has to write an example contract with such a type in its ABI.
Then make sure its type is supported as intended by abiwan.
Initially, we should aim at no nesting of generics, but if possible, we could include nesting.

Leading May 2023
issues, meeting, code reviews (3)

Currently, ABI is placed as part of https://github.com/ivpavici/abi-wan-kanabi/blob/main/test/example.ts
Issues were related to importing it.
Find a way to import it from abi.json
For implementation to work it needs to be imported as const

Leading for May 2023
meeting, issues, 3 code reviews

I'd like to use the type from the ABI for events, but at the moment StringToPrimitiveType doesn't seem to work with events.

I want to implement a type-safe event decoder so I need two things:

• ExtractAbiEvents to get a list of valid event names
• StringToPrimitiveType to get the type of the decoded event.