Missing accounts marked as signers in JS Client

[EnriqueL8]

I'm confused why the JS Client does not mark the accounts needed for signing as signers, for example when creating a transfer instruction

system/clients/js/src/generated/instructions/transferSol.ts

Lines 120 to 123 in 7e5f04e

	const originalAccounts = {
	source: { value: input.source ?? null, isWritable: true },
	destination: { value: input.destination ?? null, isWritable: true },
	};

It marks both accounts as WRITEABLE.

In createAccount as well,

system/clients/js/src/generated/instructions/createAccount.ts

Lines 140 to 143 in 7e5f04e

	const originalAccounts = {
	payer: { value: input.payer ?? null, isWritable: true },
	newAccount: { value: input.newAccount ?? null, isWritable: true },
	};

Why is this?

[lorisleiva]

Hi there,

I'm confused, it does mark them as signers. You have to pass a TransactionSigner as per the input type on both instructions.

system/clients/js/src/generated/instructions/transferSol.ts

Line 99 in 7e5f04e

source: TransactionSigner<TAccountSource>;

system/clients/js/src/generated/instructions/createAccount.ts

Lines 116 to 117 in 7e5f04e

	payer: TransactionSigner<TAccountPayer>;
	newAccount: TransactionSigner<TAccountNewAccount>;

[EnriqueL8]

You need to know before creating the instruction which fields are the signers instead of the create instruction telling you these are the signers you need for this

[lorisleiva]

Again, I'm a bit confused about why you think this is the case. TypeScript will throw a type error if you try and pass anything other than a signer as input. You don't need to know anything. It's all explicitly typed.

[EnriqueL8]

Sorry let me explain with a bit more detail, let's say I want to front the system program client by an API to build system programs. The input to that API is purely JSON based, so the signer would be a base58 encoded string in a field such as source or payer or authority or whatever. Instead of me being able to pass that to the SDK and it figuring out who is the signer, I need to do translation of:

• the authority is passed in so that is the signer , this doesn't add signer to the accounts so need to add manually
• the multiSigners is passed in so they are the signers, and authority is actually just an address to the multiSign account.

Maybe this is not the intended consumer of this, and writing a wrapper around this is the correct approach

[lorisleiva]

Damn sorry for the late reply this must have been buried in my GitHub notifications.

If I understand correctly, the issue is that the developer has to understand that:

• Passing authority as a signer means not using multi-signers.
• Passing authority as an address means using multi-signers which must be passed in the appropriate multiSigners array.

And you are suggesting that these helpers should be specific to these two use-cases so users don't have to understand this wiring.

If so, then you're not wrong. Having separate helpers could help the developer experience slightly. However these helpers are generated which means they are designed how the program designed them. In a way, there's also value in having helpers that don't deviate too much from the program's design decision to avoid having multiple mental models over the same thing. That being said, additional helpers on top of lower-level helpers could be beneficial to some people.

We're adding a new DX improvement layer on top of these generated helpers called Kit Plugins. Perhaps this could be the place to have two functions for these two use-cases.

I could be completely off though so do let me know if I got that right haha.