-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat: PrivateKey
type
#1232
feat: PrivateKey
type
#1232
Conversation
✅ Deploy Preview for preeminent-bienenstitch-606ad0 canceled.
|
merging master to check the l1 contracts ci issue is fixed |
ea80040
to
7bf6ed0
Compare
yarn-project/aztec-cli/src/index.ts
Outdated
@@ -9,8 +9,8 @@ import { | |||
createAztecRpcClient, | |||
getAccountWallet, | |||
} from '@aztec/aztec.js'; | |||
import { PrivateKey } from '@aztec/circuits.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can export this from aztec.js to avoid bringing in the extra dependency.
I can also do it in my PR as I've done a few of these already
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make sense to export that through types package (that one is in deps). Will do it like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 12cc87f
7bf6ed0
to
12cc87f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I think you may have to add PrivateKey
to getHttpRpcServer
& createAztecRpcClient
and ensure that it has toString
& fromString
implementations
f7b889c
to
2e8f0ed
Compare
Description
yarn-project/circuits.js/src/types/partial_contract_address.ts
to individual files.scalar
param toprivateKey
because having scalar being typePrivateKey
is weird and we don't ever use these classes with scalars which are not a representation of private key. For this reason I think it's ok to have the parameter name be less generic. Another alternative I considered was having aScalar
type andPrivateKey
being a type alias of it but given that we don't use non-private-key scalar anywhere in our TS codebase I think that's unnecessary complication.e2e-account-contract
toe2e-account-contracst
so that the job name is consistent with the test name.Checklist: