lang, ts: decamelize idl

[kevinheavey]

Summary of changes:

• Takes IDL camel-casing out of the Rust code
• Adds camelization logic to the Program constructor in the TS code so that this._idl still looks like it did before, even though the IDL file no longer has camelization everywhere. Also adds some stuff to make the type checking happy with this new arrangement.

The idl.ts changes look like a lot more than they are. It's just going through each property in the IDL and adding 🐫 where needed.

Closes #896

[sungoki]

Please do this! I don't think there should be any transformations done when generating the IDL.

[paul-schaaf]

@kevinheavey apart from the merge conflicts, is this ready for review?

[kevinheavey]

@kevinheavey apart from the merge conflicts, is this ready for review?

Yes!

[paul-schaaf]

I updated this PR so it no longer has any conflicts but while doing so I realised that there's more work to be done.

It's been a while so let me begin by asking if youre still interested in working/have the time to work on this PR?

The problem is as follows. The idl generation no longer generates camelCase code. This means that the types.ts is also not camelcased. A program in the ts client is created like thisProgram<IDL> where IDL comes from the types.ts file.
Thanks to the new camelCasing code in the ts client, you can still call functions using camel case but their type is snake_case. This is because of this signature function camelCaseIdl<IDL extends Idl = Idl>(rawIdl: RawIdl): IDL. camelCase returns a type of IDL which is snake_case type from the types.ts file.

• one quick fix is to adjust the idl generation code so it generates the idl with no changes but the types.ts file with camelCase. If we do this, do we even need any camelcasing code in the ts client? I guess so because the functions and other variables still have to be attached to the dynamic client. Does that sound right?
• another fix is to use some advanced typescript wrapper types that turn their inner type into a camelcased one

I lean towards just having types.ts be camelCased so the ts types code doesn't get more complicated than it already is and because it makes sense to me that a ts field has the expected casing for a ts file

[kevinheavey]

Yeah I don't have time to work on this for the next while 😅 but I agree that this option seems better:

one quick fix is to adjust the idl generation code so it generates the idl with no changes but the types.ts file with camelCase

[paul-schaaf]

ok thanks for letting me know Ill finish it then!

[Juici]

I updated this PR so it no longer has any conflicts but while doing so I realised that there's more work to be done.

It's been a while so let me begin by asking if youre still interested in working/have the time to work on this PR?

The problem is as follows. The idl generation no longer generates camelCase code. This means that the types.ts is also not camelcased. A program in the ts client is created like thisProgram<IDL> where IDL comes from the types.ts file. Thanks to the new camelCasing code in the ts client, you can still call functions using camel case but their type is snake_case. This is because of this signature function camelCaseIdl<IDL extends Idl = Idl>(rawIdl: RawIdl): IDL. camelCase returns a type of IDL which is snake_case type from the types.ts file.

* one quick fix is to adjust the idl generation code so it generates the idl with no changes but the types.ts file with camelCase. If we do this, do we even need any camelcasing code in the ts client? I guess so because the functions and other variables still have to be attached to the dynamic client. Does that sound right?

* another fix is to use some advanced typescript wrapper types that turn their inner type into a camelcased one

I lean towards just having types.ts be camelCased so the ts types code doesn't get more complicated than it already is and because it makes sense to me that a ts field has the expected casing for a ts file

I've written a demo of type level camel casing, but whilst it works perfectly it's horrifically slow; it takes a few seconds to convert one type to camel case. The biggest problem is TypeScripts lack of type level range comparisons, so I have to generate large unicode table types for checks.

https://github.com/Juici/camelcase-ts

[Juici]

I've improved upon my demo and the performance is much better now. It can now reasonably convert type strings to camel case in real-time.

[Henry-E]

Seems like maybe something worth revisiting at some stage. Not sure what the current casing behaviour is like

[acheroncrypto]

Superseded by #2824.