Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@interface tag on discriminated union results in inappropriate broadening of some property types, omission of others #2352

Closed
Oblarg opened this issue Jul 31, 2023 · 2 comments
Labels
bug Functionality does not match expectation design-limitation

Comments

@Oblarg
Copy link

Oblarg commented Jul 31, 2023

Consider:

type Foo = {
  key: 'foo'
  bar: 'bar1'
}

type Bar = {
  key: 'bar'
  bar: 'bar2'
  baz: any
}

/**
 * @interface
 */
type DiscriminatedUnion = Foo | Bar;

This renders as:

{
  key: 'foo' | 'bar'
  bar: 'bar1 | 'bar2'
}

The type above is overly-broad with respect to the key and bar properties (their values are correlated), and omits the baz property entirely.

@Oblarg Oblarg added the bug Functionality does not match expectation label Jul 31, 2023
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Aug 1, 2023

The way @interface works is effectively to run your type through { [K in keyof T]: T[K] } and convert that, TS interfaces don't support unions like this, and neither does @interface

@Oblarg
Copy link
Author

Oblarg commented Aug 1, 2023

I am aware that TS interface does not support discriminated union semantics - but I think it's a bad behavior to just strip them/represent them wrongly without warning. It'd be better to error here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality does not match expectation design-limitation
Projects
None yet
Development

No branches or pull requests

2 participants