chore(js): Add plugin & instruction planner defaults#128
chore(js): Add plugin & instruction planner defaults#128amilz wants to merge 4 commits intosolana-program:mainfrom
Conversation
…efaults - export async input types for mintToATA and transferToATA - make ata, source, destination, and tokenProgram optional on async variants (derived via PDA when omitted) - default mintAuthority and authority to client.payer in plugin - default mintAuthority to client.payer.address in createMint plugin method - add offline plan-inspection tests for address derivation paths
- add src/types.ts with shared MakeOptional utility - export *InstructionPlanConfig types from createMint, mintToATA, transferToATA - remove tokenProgram from async input types (use config instead) - plugin instructions now accept optional config as second arg and pass it through
clients/js/src/plugin.ts
Outdated
| { | ||
| ...input, | ||
| payer: input.payer ?? client.payer, | ||
| mintAuthority: input.mintAuthority ?? client.payer.address, |
There was a problem hiding this comment.
This is a tricky assumption.
Yes, most of the time you'll want the payer to be the authority or owner of anything you do with a program but not always. The assumption with client.payer is that this is going to be the wallet that pays for things like transaction fees and rent fees.
Codama actually has got two different nodes for identifying a user:
PayerValueNode: Meaning this account is used to pay for things.IdentityValueNode: Meaning this account is used to identify the user interacting with the app. This would be a better contender for things likemintAuthorityhere.
Because Codama already has "identity" knowledge, it would be possible to generate that change, just like we do currently with the payer. This means though we need to introduce a client.identity wallet on the client and have plugins that can set both of these things to be the same by default.
I wanted to wait a little before introducing too many concepts to default clients to avoid overwhelming devs but this is something we can implement soon.
My other concern is that we'd be automatically filling important signer values for devs. Values that could have dangerous consequences if they just forgot to fill them or didn't know it was there. If you forget to inject a payer or put the wrong one, you end up with either an error or the wrong wallet that paid for a few fees. If you get the authority wrong, this can have irreversible consequences. This is why there is also a case for not introducing default values for identity accounts such as authority, owner, etc. and instead force the developer to explicitly set this information.
There was a problem hiding this comment.
- like the idea of
client.identity-- the delineation would help us in our kora plugin, actually. - fair point re: auth/owner/etc. I'm fine leaving it off for now--we can chat about it and maybe revisit later.
Only payer is defaulted in the plugin; callers must provide mintAuthority and authority explicitly. Replace mock/plan-inspection tests with integration tests against localhost validator.
Adds additional optional fields/default derivations for InstructionPlanners and Plugin
Changes
createMint,mintToATA, andtransferToATAinstruction helper functions with optional ATA/source/destination derivationconfigsecond param and pass it through to underlying functions (giving access tosystemProgram,tokenProgram,associatedTokenProgramoverrides, matching instruction configs)MakeOptionalutility type for handling defaults (borrowed from generated codama code)Testing
npx tsc --noEmitpassespnpm run clients:js:test)Before
After