Variant names clash in TypeScript

[yannbolliger]

We have some WITs:

variant operation {
  create(operation-create),
  edit(operation-edit)
}
record operation-create {
  credit: u64,
  metadata: metadata, // some other record
}
record operation-edit {
  credit: u64
}

This generates the following TypeScript:

export type Operation = OperationCreate | OperationEdit;
export interface OperationCreate {
  tag: 'create',
  val: OperationCreate,
}
export interface OperationEdit {
  tag: 'edit',
  val: OperationEdit,
}
export interface OperationCreate {
  credit: bigint,
  metadata: Metadata,
}
export interface OperationEdit {
  credit: bigint,
}

⚡️ the problem is that two interfaces now alias each other. This makes TypeScript merge the declarations and we have a recursive type. 🤯

In general, if a variant has a record field that has as name the concatenation of the variant/enum and the variant branch, the generated TypeScript will contain clashing interface declarations.

Could the generator maybe check if the name is not already present/generated to avoid this?

(We generate these WIT from Rust enums. Therefore, enum variants with named fields are extracted to records that concat the name of the enum with the name of the variant. Of course, we can quick-fix this by changing our generator but the issue is still relevant.)

[vados-cosmonic]

Hi @yannbolliger thanks for finding this -- this is certainly a bit of a problem on the naming side.

What kind of types were you expecting the generator to generate? I don't think we should chase down every craftable name collision, and there are many options but maybe in this case it might be better to generate enums completely differently here in the first place.

One solution that springs to mind is by using Typescript's const enums, but that would still be a breaking change/need to be opt in. What do you think of that as a solution?

[yannbolliger]

I agree that the tool cannot avoid any naming collision. However, due to the fact that WIT variants can only have a single field type, I suspect that concatenating the name of the variant/enum and the variant branch/Rust variant is quite common. So this clash here is likely to reappear.

My suggestion is: surely, the generator sees all names of types it's going to generate in one interface. Then, for enums it could just check whether the concatenation is not already taken and if so, add something to the name to make it unique, like Variant or Enum. Actually, it could even do that by default...

[vados-cosmonic]

I agree that the tool cannot avoid any naming collision. However, due to the fact that WIT variants can only have a single field type, I suspect that concatenating the name of the variant/enum and the variant branch/Rust variant is quite common. So this clash here is likely to reappear.

In Rust this problem is avoided since we have namespaces (i.e. Operation::Create(...)) -- I'd like to avoid OperationOperationCreate or OperationCreateOperationCreate if we can. The const enum approach seems to avoid this via namespacing -- i.e. we would have Operation.Create here.

My suggestion is: surely, the generator sees all names of types it's going to generate in one interface. Then, for enums it could just check whether the concatenation is not already taken and if so, add something to the name to make it unique, like Variant or Enum. Actually, it could even do that by default...

I'm hesitant to do this as it this should be solvable via policy/consistent generation rules, rather than introducing possible inconsistencies across different cases. Sure we could detect and generate differently, but having a consistent policy that avoids the problem via proper namespaces is probably ideal.

[yannbolliger]

Clearly, the solution should be a consistent policy. That's why the generator could always add a suffix to the variant types in the type union.

const enums don't work for rich WIT variants with data however. They can only represent TypeScript enums but not the full richness of WIT variants or Rust enums. From a Typescript perspective, the union type is good and should stay. It would just have to avoid naming collisions.

[vados-cosmonic]

Clearly, the solution should be a consistent policy. That's why the generator could always add a suffix to the variant types in the type union.

Yes this is certainly one solution -- it's the most straight forward solution, but if we could get namespacing similar to the Rust translation without having to making the names longer that would be ideal.

const enums don't work for rich WIT variants with data however. They can only represent TypeScript enums but not the full richness of WIT variants or Rust enums. From a Typescript perspective, the union type is good and should stay. It would just have to avoid naming collisions.

Yes you're right -- they're the wrong solution here. There is a way to constrain the types of regular enums, but it would take away some of the safety.

What I was trying to get at is that there should be a way we can express this without creating the intermediate types for the variants in the first place.

Here's a more fleshed out idea:

export interface OperationCreate {
  credit: bigint,
  metadata: string, // just replacing this for simplicity
}

export interface OperationEdit {
  credit: bigint,
}

type _Operation<T> = T extends 'create' ? { tag: T, val: OperationCreate } : T extends 'edit' ? { tag: T, val: OperationEdit } : never;

type Operation = _Operation<'create' | 'edit'>;

const exampleEdit: Operation = { tag: 'edit', val: { credit: 0n } };
const exampleCreate: Operation = { tag: 'create', val: { credit: 1n, metadata: "meta!"}};

This makes it a bit hard to name the variants individually, but I wonder if we need that to begin with.

[vados-cosmonic]

Actually it's not that hard to address the variants if we use _Operation directly -- you could use _Operation<'create'> to address an individual variant (of course we should probably name it something different if it would be exposed).

Again, it's not clear whether people should actually be using that type in that way though -- the type most people should be referencing is Operation, not the type for a specific variant.