Krešimir Klas

You can always load the program ID through an env var for example. Alternatively you can generate multiple clients for different program IDs. I don't think that being able to...

Yes, the env vars are hard-coded into the bundle by the bundler. So if you're using CRA you can do for example: ``` // programId.ts ... export const PROGRAM_ID: PublicKey...

Could be useful in some cases but I don't think it's super useful. A lot of people will probably do something like: ``` export const PROGRAM_ID: PublicKey = config.myProgramId ```...

Can't you do ''' export const PROGRAM_ID: PublicKey = new PublicKey(MY_PROGRAM_ID_); ''' ? Either that or define all your constants in a separate ts file and import it here.

> and I really don't like the idea of having generated code import a project file Why not? I find it quite convenient. But also making the generator not overwrite...

Isn't `Vec` already encoded as Uint8Array after that PR? In any case, technically for "bytes" fields it makes sense to be Uint8Array because: - there is a specific type in...

> apparently we won't be able to support Uint8Array at all and always need to pass Buffer when interacting with borsh We're not sending Uint8Array anywhere to borsh. Buffer is...

> How are these currently handled? They're handled as array of numbers both in IDL, borsh layout, and the generator. > I'm mainly concerned with input validation for overflows, when...

I have thought about this but the reason I didn't add it in is because the remaining accounts aren't in the IDL so there's no way to generate anything useful...

Hmm probably not in that case. But should it be possible to pass object fields that are not defined in the schema through the API in the first place? I...