Add default type values to parse functions in js-experimental

[mcintyre94]

Currently when we generate a ParsedXInstruction type it has sensible default type params:

export type ParsedTransferSolInstruction<
  TProgram extends string = "11111111111111111111111111111111",
  TAccountMetas extends readonly IAccountMeta[] = readonly IAccountMeta[],
> = {

But the parseXInstruction doesn't have default type params:

export declare function parseTransferSolInstruction<
  TProgram extends string,
  TAccountMetas extends readonly IAccountMeta[],
>(instruction: <snip>
): ParsedTransferSolInstruction<TProgram, TAccountMetas>;

This means that the ParsedXInstruction type returned by parseXInstruction(instruction) returned ParsedXInstruction<string, readonly IAccountMeta[]>

This causes a problem because the definition of ParsedSplSystemProgramInstruction includes ParsedTransferSolInstruction without specifying type params, ie using the default of the program ID

Therefore we get a type error if we try to do:

const parsedInstruction = parseTransferSolInstruction(instruction)
const x: ParsedSplSystemInstruction = {
  instructionType: SplSystemInstruction.TransferSol,
  ...parsedInstruction // program address incompatible, got string, expected programID 
}

I think the best fix is to just add the default type params to the parseXInstruction function to match the ParsedXInstruction type, which is what this PR does

Most changes are a result of the generated test being updated, since this changes the parse function in each instruction. Non-generated changes are to src/renderers/js-experimental/fragments/instructionParseFunction.njk + https://github.com/metaplex-foundation/kinobi/compare/main...mcintyre94:cm-default-parse-types?expand=1#diff-7924ecc400cbdbf956997331e2f3f3736f6405fd3649c66d314961724d8d89ac

[changeset-bot]

🦋 Changeset detected

Latest commit: b4a188a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@metaplex-foundation/kinobi	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lorisleiva]

I think a better fix would be to parameterise the generated union type like so:

export type ParsedSplSystemInstruction<TProgram extends string = "..."> =
  | ({
      instructionType: SplSystemInstruction.CreateAccount;
    } & ParsedCreateAccountInstruction<TProgram>)
  | ({
      instructionType: SplSystemInstruction.TransferSol;
    } & ParsedTransferSolInstruction<TProgram>);

I'm not a big fan of providing default values to function type parameters because IIRC there are some cases where it affects the type inferences.

[mcintyre94]

Do you mean make it export type ParsedSplSystemInstruction<TProgram extends string = string> =? That should work, because we'd loosen the type of the ParsedTransferSolInstruction to any string. But putting the program ID in there is the same as what we already have, because ParsedTransferSolInstruction is defaulting to its program ID.

FWIW we can also not change this, and pass the responsibility to the caller: const parsedInstruction = parseTransferSolInstruction<typeof SPL_SYSTEM_PROGRAM_ADDRESS, readonly IAccountMeta[]>(instruction);. And you'll only need that when you do care about the TProgram on ParsedTransferSolInstruction. So it's not critical

[mcintyre94]

Closing - I'll open a separate PR to parameterise the ParsedXInstruction type but fix this specific issue with better instruction narrowing in web3js.