feat(associated token pda search): add tokenProgramId param

[shotgunofdeath]

Description:

findAssociatedTokenPda() is updated. Now it accepts another seed - tokenProgramId. It’s a specific public key for either Token or Token2022 Program as we discussed with @blockiosaurus. Tests are updated accordingly.

NB! JS tests will fail because findAssociatedTokenPda() is used in generated by Kinobi instructions. Specifically:
src/generated/instructions/createAssociatedToken.ts
src/generated/instructions/createTokenIfMissing.ts

And generated files shouldn’t be changed manually.

BREAKING CHANGE: the tokenProgramId param for the findAssociatedTokenPda() function breaks js tests which use instructions generated by Kinobi. It will also break any code relying on this function.

[shotgunofdeath]

Not sure if it’s correct or necessary. But I have some suggestions to simplify the usage of findAssociatedTokenPda() for end users. We can make it accept not a specific PublicKey type but either a flag with a default value or string with a token program name for umi and find the necessary public key in the function itself. E.g.

isToken2022: boolean = false
const tokenProgramId = context.programs.getPublicKey(
    isToken2022 ? 'splToken2022' : 'splToken'
  );

or

tokenProgramIdVersion: 'splToken' | 'splToken2022' = 'splToken'
const tokenProgramId = context.programs.getPublicKey(tokenProgramVersion)

Also I’m not sure whether specific PublicKeys types and constants for token programs should be defined in mpl-toolbox. It seems it’s better to have them on some another level, e.g. in umi itself.

[lorisleiva]

Hi there, have you seen this?

https://solana.stackexchange.com/a/9121/1668

[shotgunofdeath]

Hello there! No, not before you've shown this.

[lorisleiva]

My point before was that this manually written function follows the convention of what is generated by Kinobi and therefore allows devs to swap program via Umi's program repository.

This change would break that convention and that function would now behave differently then the rest of the Umi's PDA helpers which I wouldn't recommend.

If you don't like the idea of using the program repository, I would at least suggest accepting the token program as an input and, when not provided, resolving it from Umi's program repository as a fallback so this doesn't introduce a breaking chance.

[blockiosaurus]

My point before was that this manually written function follows the convention of what is generated by Kinobi and therefore allows devs to swap program via Umi's program repository.

This change would break that convention and that function would now behave differently then the rest of the Umi's PDA helpers which I wouldn't recommend.

If you don't like the idea of using the program repository, I would at least suggest accepting the token program as an input and, when not provided, resolving it from Umi's program repository as a fallback so this doesn't introduce a breaking chance.

Yes but doing it via the program repository wouldn't work for programs using both SPL token programs at the same time. Token22 set the pretend of spl-token no longer being special, which this change reflects.

[lorisleiva]

You could bind and unbind afterwards but I understand that having an explicit input might be better for Devex. However, if the token program is not provided explicitly, we should fallback to resolving the program via the repository so that this change isn't a breaking one and so that this function is still consistent with the rest of the generated function.

[shotgunofdeath]

@blockiosaurus I've made some changes according to @lorisleiva recommendations. Let me, please, know if it's OK with you both, guys.

7f33d3b

[lorisleiva]

Much better, thanks!

[blockiosaurus]

This looks great, thank you!

[shotgunofdeath]

This looks great, thank you!

Thank you!

@blockiosaurus @lorisleiva Appreciate all the help!
I've squashed the fixup commits. I guess you could merge and publish now.