TypeScript binding generation doesn't handle invalid identifiers or reserved word collisions

[leighmcculloch]

What problem does your feature solve?

When generating TypeScript bindings for Soroban contracts, certain valid Soroban identifiers produce invalid TypeScript/JavaScript code:

1. Leading digits: A contract function named 123foo generates an identifier that starts with a digit, which is invalid in JS/TS
2. Empty names: An empty name produces an empty identifier, which is invalid
3. Reserved words: Names like class, function, delete, export, import, etc. are valid Soroban identifiers but are reserved keywords in JavaScript/TypeScript

When a contract uses any of these as function names, struct names, field names, or enum variants, the generated TypeScript bindings will fail to compile.

What would you like to see?

The binding generator should produce syntactically valid TypeScript identifiers:

1. Leading digits: Prefix with underscore (e.g., 123foo → _123foo)
2. Empty names: Replace with a placeholder like _ or _empty
3. Reserved words: Append underscore suffix (e.g., class → class_) — this is a common convention in code generators

Note: The JS Stellar SDK also generates functions dynamically from contract specs. Any identifier mapping rules implemented here should be synchronized with the JS Stellar SDK to ensure consistent behavior. There are plans to move the TypeScript binding generation functionality from stellar-cli into the JS Stellar SDK. If that migration happens before this issue is addressed, this issue should be moved to that repository.

What alternatives are there?

• Fail at generation time: Reject contracts with problematic names and require users to rename them. This is more disruptive.
• Do nothing: Accept that some contracts will produce invalid bindings. Users would need to manually fix generated code.

[leighmcculloch]

It's actually not clear to me how the JS Stellar SDK when dynamically generating from contract specs would handle these cases as well. So it'd be very interesting to do some research there to see how that plays out.

[mootz12]

cc @Ryang-21

do we want to implement this in the CLI binding generation or just leave it for the JS implementation?

[leighmcculloch]

Adding my 2 cents that I think it would be very reasonable to defer this for the JS implementation.

[Ryang-21]

I agree I think we can defer this to the JS implementation