Missing alternatives for types containing nested tuples

[sander2]

See the discussion in #5395.

Tl;dr: not all alternatives are created by the type generator when the type contains nested tuples.

[jacogr]

These are most-probably tricky without getting yourself into knots. And not getting into knots is why enums still have aka { Key: any }. Anyway, if this does become a problem immediately, we probably can also do a any solution inside the []'s as an interim stopgap like we do with enums.

(Although we know the "stopgap" will also last a while. Granted, I have not looked in ages, it could have been pure lazyness on my side at original implementation time...)

[rajk93]

I've investigated this issue and found that nested tuple alternatives are being generated, but not all possible combinations.

Current Behavior?

For a nested tuple like ITuple<[ITuple<[CurrencyId, CurrencyId]>, AccountId32]>, the generator creates:

  [
    ITuple<[CurrencyId, CurrencyId]> | [EXPANDED_CURRENCY_ID, EXPANDED_CURRENCY_ID],
    AccountId32 | string | Uint8Array
  ]

This provides the canonical form plus array alternatives with proper nested unions. Tests in packages/typegen/src/util/derived.spec.ts confirm this works correctly.

The Challenge?

As noted in #5395, generating all possible combinations would create exponential type explosion:

• 2 form choices (ITuple vs Array) at each nesting level
• 2 content choices (either default or expanded)
• For the InterBTC example: 2 × 2 × 2 × 2 × 2 = 32 combinations

This would make types unreadable, slow compilation, and be unmaintainable.

Proposed Solutions

Option 1: Close the issue(Recommended):

Since current alternatives cover most common use cases and maintain equivalent type safety. Users can cast to any manually for rare edge cases.

Rationale: This approach preserves type safety without introducing potential anti-patterns into the codebase.

Option 2: Add any[] Escape Hatch (like enums)

It can handle edge cases, but it weakens type safety and removes compile-time validation, which might go against TypeScript best practices.