Fix link/core/types to be compatible with graphql typings while TypeScript exactOptionalPropertyTypes mode is enabled

[nevir]

When importing @apollo/client in a project with TS 4.9, graphql 16.6 and strict: true and exactOptionalPropertyTypes: true, we see the following compilation error:

./node_modules/@apollo/client/link/core/types.d.ts(44,18): error TS2430: Interface 'SingleExecutionResult<TData, TContext, TExtensions>' incorrectly extends interface 'ExecutionResult<TData, TExtensions>'.
  Types of property 'data' are incompatible.
    Type 'Data<TData>' is not assignable to type 'TData | null'.
      Type 'undefined' is not assignable to type 'TData | null'.

Because Data<TData> expands to:

  data?: TData | undefined | null

Which is subtly different from:

  data?: TData | null

E.g. the GraphQL types are declaring that data can be not present in the object, but it should not be explicitly { data: undefined }.

For extra context, check the TypeScript docs on the exactOptionalPropertyTypes flag

---

This fixes the type to be compatible.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4d552b2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@apollo/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[alessbell]

Hi @nevir 👋 I'd like to understand the problem a bit better; I've tried to reproduce this and wasn't able to in https://github.com/apollographql/router-defer-e2e-tests.

If you clone that repo, cd into CRA-demo, npm i && npx tsc you should see 0 problems reported by TS. That project is using TS 4.9, graphql 16.6 and both strict: true and exactOptionalPropertyTypes: true as you've mentioned. If you have further reproduction steps/a reproduction I can look at that would be a huge help, thanks!

[alessbell]

Looks like FetchResult.data was updated to explicitly include undefined in AC 3.5.0: 24799a9#diff-5e2dbe69feb4479799e4247c4d09edd3c9f6255ce84522aece23a5478cf2644aR28

Removing undefined from its possible values (while keeping the data key as optional) would technically be a breaking change, but it's one I'm in favor of. I propose targeting this at the next minor release (3.8) - thoughts @jerelmiller @phryneas?

[alessbell]

LGTM ✅