Enable type check for nonexistent fields

[ivari]

Our team wants to use this library to cut down on Typescript boilerplate… and boy, do we overtype our requests.

For full typings experience we also want the build to fail on issues – which happens in most cases, but not one. I would like to describe that one case below.

Scenario

Consider the following code:

import { useQuery } from '@apollo/client'
import { graphql } from 'gql.tada'
import React from 'react'

export const Tada = () => {
  const query = graphql(`
    query getFields {
      fields {
        id
        name
        active
      }
    }
  `)

  const { loading, data } = useQuery(query)

  if (loading || !data || !data.fields) {
    return null
  }

  return data.fields.map((field, index) => (
    <div key={index}>
      {field.id}: {field.name} ({field.active ? 'yes' : 'no'})
    </div>
  ))
}

The query has fields id and name, but not active

In the IDE, I can see an error: Cannot query field "active" on type "Field"

The type of data.fields is Array<{id: number, name: string, active: unknown }>

Calling active does not throw an error.

The issue for us here is that the error above is not actually a Typescript error, as it is handled by the LSP. So running tsc --noEmit, vite checker plugin, or just building the project won't fail on this missing field, and we are back to runtime errors in production.

Proposed solution

What if you were to return the missing field as type void instead of unknown? In that case Typescript would natively error out on most attempts to use or assign said variable.

With the type of data.fields being Array<{id: number, name: string, active: void }>, calling field.active fails as expected.

Now, I have no idea if that would break some other behaviour. Hence putting up this thread first, not a PR. Also it's not exactly a bug, I think.

I think the code we are talking about is this line:

gql.tada/src/variables.ts

Line 42 in 1a0b07b

: unknown;

[JoviDeCroock]

We're currently working on that through gql.tada check as a CLI command which will output the errors of the LSP, I do understand the want for this to be natively in the types as well.

[kitten]

The issue for us here is that the error above is not actually a Typescript error, as it is handled by the LSP. So running tsc --noEmit, vite checker plugin, or just building the project won't fail on this missing field, and we are back to runtime errors in production.

None of the options we have for typing an undefined field (as per the GraphQL schema) are really satisfactory:

• leaving the field out isn't really an option without added complexity
• leaving the field out it risks empty objects, which can collapse types incorrectly
• unknown is a good choice when there's no selection set
• never technically creates a better situation for fields without selection sets, but still signifies the presence of the field

I don't really want to list out all cases, but tl;dr there isn't really a great representation of a field that isn't on the schema, because it simply isn't a possible “state” i.e. the query will fail, there is no corresponding type, etc etc

As you're saying the IDE protects you against this, and what we have planned is rather that the CLI will hard-error on these cases: #76

[ivari]

Thank to both of you for quick replies. A CLI check would be perfect for our needs. Looking forward to it!