TypeScript will complain about the generated js code, when either the verbatimModuleSyntax or importsNotUsedAsValues compiler options are set.

I am currently basing some code on this repo, and it would be great if there was clarity on the licensing of the code :)

Hey! Here's a detailed review of some of my thoughts going through the generated code from Kinobi in this repository.

I'm going to attempt to use line separators to isolate thought points.

Program Getters

Do we like createJoeProgram() or getJoeProgram()?

Shared Helpers

Would it make more sense to have a package that houses all of this shared stuff? And then the generated code just imports it, like generated programs do with @solana/addresses.
https://github.com/lorisleiva/solana-core-programs/blob/main/clients/js/src/generated/shared/index.ts

Accounts and Types in IDL or Generated Modules

Anchor set the pattern for the account-type relationship, and a lot of people want it changed, including Acheron.
In Anchor IDLs, any struct that was annotated with #[account] is inferred to be the account state layout of a program-owned account. As a result, Anchor places this layout under "accounts" in the IDL, not "types".
However, you may choose to use some struct, let's say JoePdaData as a data structure for some other purpose, outside of specifically account state.
I'm curious if we have any interest in making all types land in "types" and then accounts just point to their respective type for their associated state?
On a related note, this concept can also apply to instruction data, but the instructions themselves are a repeatable interface, so we can leverage an InstructionDecoder/InstructionEncoder.
This could be overkill, but you'd end up with a slew of program-defined types, and then instructions and accounts just point to these types where used. Like a canonical Rust program, generated types (structs, enums, etc.) would be layouts that can be used anywhere, for anything.

Encoder/Decoder Syntax

I still love the encoder/decoder syntax. Man.

Safe Fetch

These are slick and useful, but does the keyword safe convey the value provided by these? In my opinion, something like nullable makes more sense, even though it looks significantly less pretty.
One could make the argument safe actually applies more to the ones with assertions.

Custom. Program Errors

The error setup is nice and robust, I dig it. Have you thought of how we might introduce a generic function (like in the "shared" tooling) that can interpret a transaction simulation error and convert to some error from your package's list of generated program errors?
Something like:

try {
  rpc.sendTransaction(tx);
} catch (e) {
  const programError = parseProgramError(e);
  if (!programError) {
    throw Error("Not a recognized program error")
  }
  if (programError === SplSystemProgramErrorCode.ACCOUNT_ALREADY_IN_USE) {
    throw Error("Account already in use.")
  }
}

The Generator is Smart

I'm really curious how the generator knows to build out this logic?

IDL Interfaces

📋 📋 Side note: is now a good time to team up with Anchor and establish an IDL interface? If there are ideas you have for expanding on IDLs/trees, we might want to make sure it always implements some interface (which may be defined already) to make sure wallets and other tooling don't have to freak out and keep up.

We can also work in conjunction with Anchor to publish upgrades to the interface where mutually beneficial.
(I can see you have a few new items in your IDLs)

Validator Config

I think I know what this does, but don't remember us talking about it on the codegen call. Love it though!
https://github.com/lorisleiva/solana-core-programs/blob/main/configs/validator.cjs

Test Shell Scripts

Are these generated?
https://github.com/lorisleiva/solana-core-programs/blob/main/configs/scripts/client/test-js.sh

BytesOnChain Configs

I can set up a config like this if I want to track bytes created on chain? Is that the primary purpose of this config entry?

Solana Tools Toml

Should we define some Solana tooling versions in the Kinobi/Amman config? ie. solana-program, @solana/web3.js, @solana/spl-token? Maybe even CLI compatibility?

We could even go so far as to leverage what would basically be a Loris-version of rust-toolchain.toml and configure the proper Solana toolkit for CLI, test validator, etc. for local testing within the repository.

I think my limited rudimentary knowledge on amman is probably showing here in that last msg, but you get the idea. Seems like you've likely got a lot of this stuff in here already, I just can't tell!

Summary

Overall I love it. I think everything is looking nice.

I also dig the repository layout. A couple random parting questions:

• I'm assuming the IDL generation for these core programs would just be Shank? If I wanted to PR the ALT program into here, we'd later want to integrate Shank into the program?
• Is there more refactoring going on to eliminate Metaplex tools and references? Not that I have a hard stance on this, but I noticed the README's and what not have lots of Metaplex stuff in them. Assuming you prob just copied this over for now, but lmk.
• wen npx create-solana-repository?

Would be cool to have a function similar to tensorswaps SDKs swapSdk.coder.instruction.decode(Buffer.from(CompiledInstruction.data)) that decodes the data based on the instruction indentifier.

It would also be cool if you could decode an instruction so accounts are included aswell smilar to tensorswaps SDKs swapSdk.coder.instruction.format(instruction, instructionAccounts)

Hey there, when getting mpl-token-metadata/alpha to work I noticed you used generated files in your example. I just copy and pasted the generated files, but I would like to know how to generate them my self. Thanks!

When I tried to generate code from the magiceden idl I got this error

SyntaxError: Identifier expected. (10:10)
   8 |
   9 | import { GetDataEnumKind, GetDataEnumKindContent, Serializer, dataEnum, struct, tuple } from '@metaplex-foundation/umi/serializers';
> 10 | import { &'refsAccountInfo<'a>, &'refsAccountInfo<'a>Args, &'refsPubkey, &'refsPubkeyArgs, get&'refsAccountInfo<'a>Serializer, get&'refsPubkeySerializer } from '.';
     |          ^
  11 |
  12 |
  13 | export type DestinationSpecifier = { __kind: "Key", fields: [&'refsPubkey];  } | { __kind: "Ai", fields: [&'refsAccountInfo<'a>];  };
    at v (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\parser-typescript.js:1:14679)
    at _H (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\parser-typescript.js:49:10722)
    at Object.cH [as parse] (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\parser-typescript.js:49:11028)
    at Object.parse (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\index.js:7515:23)
    at coreFormat (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\index.js:8829:18)
    at formatWithCursor2 (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\index.js:9021:18)
    at C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\index.js:38183:12
    at format (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\prettier@2.8.8\node_modules\prettier\index.js:38197:12)
    at render (C:\Users\alvej\Documents\NodeJS\Solana\umi-testing\node_modules\.pnpm\@metaplex-foundation+kinobi@0.17.1_fastestsmallesttextencoderdecoder@1.0.22\node_modules\@metaplex-foundation\kino