Using 'never' pattern in unions?

[chortis]

Is it possible to define property?: never in union types for properties that exist on one type but not the other? Example:

Current Behaviour

interface MyFirstType {
  __typename: 'MyFirstType',
  id: string;
  description: string;
}

interface MySecondType {
  __typename: 'MySecondType',
  id: string;
  url: string;
}

type MyType = MyFirstType | MySecondType;

The above doesn't actually work great, due to the nature of typescript unions and with really complex unions it can become a nightmare

Desired behaviour

interface MyFirstType {
  __typename: 'MyFirstType',
  id: string;
  description: string;
}

interface MySecondType {
  __typename: 'MySecondType',
  id: string;
  url: string;
}

type MyType = MyFirstType & { url?: never } | MySecondType & { description?: never };

This pattern is extremely useful and would make using the generated types a lot easier. I can't seem to find any plugins or docs around this.

Thanks!

[charlypoly]

Hi @chortis,

While I agree with your TypeScript examples, could you provide some codegen configuration reproduction of generated types that seems not optimal to you?

Thank you,

[chortis]

For sure!

So in this example below,

interface MyFirstType {
  __typename?: 'MyFirstType',
  id: string;
  description: string;
}

interface MySecondType {
  __typename?: 'MySecondType',
  id: string;
  url: string;
}

type MyType = MyFirstType | MySecondType;

// query data
const valueFromQuery: MySecondType = {
  __typename: 'MySecondType',
  id: '123',
  url: 'http://github.com'
};

// this method throws two type errors that url is not defined on `MyFirstType` without also checking `__typename`.

const getUrl = (args: MyType) => {
  if (!args.url) {
    throw Error('No Url!')
  }

  return args.url
};

getUrl(valueFromQuery);

Now in this example above, the easy way to additionally check for __typename === 'MySecondType'. But in large data with nested objects, arrays etc, this can become pretty cumbersone, throw difficult to read errors and be generally frustrating, especially when we have to write tests or change the schema. It's also just adding more code to satisfy TS, which I'm not a fan of usually.

Using never fixes this problem, as if url doesn't exist, TS is able to infer it's MySecondType without additional checks.

Let me know your thoughts.

Cheers

[charlypoly]

Hi, can you share the codegen configuration that leads to such generated types?

[chortis]

🤦‍♂️ My bad I completely misunderstood what you were asking the first time. Apologies for wasting your time there.

We definitely need to take at our configuration, and I have some tasks, but here is the config section right now (we're also on an older version which we have tasks to update):

Versions:

• @graphql-codegen/add: 3.1.1
• @graphql-codegen/cli: 2.3.1
• @graphql-codegen/fragment-matcher: 3.2.1
• @graphql-codegen/typescript: 2.4.2
• @graphql-codegen/typescript-compatibility: 2.1.5
• @graphql-codegen/typescript-operations: 2.2.2

Obviously I would like to update these.

  "config": {
    "typesPrefix": "I",
    "avoidOptionals": true,
    "maybeValue": "T | null | undefined",
    "scalars": {
      "DateTime": "string",
      "Date": "string"
    }
  }

Some things I am looking to change:

avoidOptionals: false
maybeValue: T

We also have some pretty wild naming but that is due to some plugins and can be addressed elsewhere.

Thanks for your help.

Curtis

[charlypoly]

@chortis, after searching in my memories, I reminded that @n1ru4l recently shipped a new feature in codegen (the support for @oneOf directive on input types) that adopt the union pattern that you describe, for example, here: https://github.com/dotansimha/graphql-code-generator/pull/7886/files#diff-d3cc53411a5d461219e906fa895dbcea19f5d7e60ab44203834c3f9f40058681R2658-R2659

I am not sure that we will apply the same pattern for other types since it could lead to way bigger generated types.
However, please know that this is an already known issue on the TypeScript project (I remind reading an issue on that, but I don't remember where)

[chortis]

Sorry for the delay on reply. Thanks very much, I'll look into this. In terms of large generated types, is could be optional depending on the project. I find very large types aren't really a big issue as they don't end up affecting the product in browser and some aren't worried about total package size.

Thanks!