o1-labs / o1js

TypeScript framework for zk-SNARKs and zkApps

Home Page:https://docs.minaprotocol.com/en/zkapps/how-to-write-a-zkapp

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add type exports to mina-signer to make it easier to use with typescript

jrwashburn opened this issue · comments

I don't think this warrants an RFC; if it does, please close, and I can resubmit with an RFC and proposed solution.

Maybe I'm doing it wrong - and if so, the mina-signer docs could use an update. If not ...

It's difficult to use/define the proper types for mina-signer. For example, I needed to dig to find and import the types needed for a signed payment here:

https://github.com/jrwashburn/mina-pool-payout/pull/132/files#diff-9a2c2616455f919682a2117c56a9a2d2cda0e7708e3e2dd08a67076aef7e6969

And ended up with this import to get things working.

import { SignedLegacy, UInt64, UInt32, } from 'mina-signer/dist/node/mina-signer/src/types';

It would be better if types such as Payment, KeyPair, PublicKey, PrivateKey, etc., were easy to find and import, and it seems odd that the signer returns SignedLegacy. This was in no way a compatible change, so it doesn't seem that Legacy makes sense.

I agree that type exports would make writing code like yours more convenient.

For what it's worth you could have also gotten SignedLegacy<Payment> using

type SignedPayment = Awaited<ReturnType<typeof minaClient.signPayment>>;

This was in no way a compatible change, so it doesn't seem that Legacy makes sense.

I guess the point is that there was no change in the content of the data contained in the SignedLegacy type, and in the endpoint.. Literally, a payment created with the old client SDK can still be used and sent to the network. It's legacy in that sense, the tx layout and signature method didn't change.

I also think maybe we should just remove the various type aliases for string

Fair point re: legacy