chore(deps): update dependency @graphql-codegen/typescript to v4 #426

renovate · 2024-06-15T00:16:28Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@graphql-codegen/typescript (source)	`2.8.7` -> `4.0.9`

Release Notes

dotansimha/graphql-code-generator (@graphql-codegen/typescript)

Patch Changes

#9497 2276708d0 Thanks @eddeee888! - Revert default ID scalar input type to string

We changed the ID Scalar input type from string to string | number in the latest major version of typescript plugin. This causes issues for server plugins (e.g. typescript-resolvers) that depends on typescript plugin. This is because the scalar type needs to be manually inverted on setup which is confusing.
Updated dependencies [2276708d0]:
- @graphql-codegen/visitor-plugin-common @4.0.1

`v4.0.0`

Compare Source

Major Changes

#9375 ba84a3a27 Thanks @eddeee888! - Implement Scalars with input/output types

In GraphQL, Scalar types can be different for client and server. For example, given the native GraphQL ID:

A client may send string or number in the input
A client receives string in its selection set (i.e output)
A server receives string in the resolver (GraphQL parses string or number received from the client to string)
A server may return string or number (GraphQL serializes the value to string before sending it to the client )

Currently, we represent every Scalar with only one type. This is what codegen generates as base type:

export type Scalars = {
  ID: string;
};

Then, this is used in both input and output type e.g.

export type Book = {
  __typename?: 'Book';
  id: Scalars['ID']; // Output's ID can be `string` 👍
};

export type QueryBookArgs = {
  id: Scalars['ID']; // Input's ID can be `string` or `number`. However, the type is only `string` here 👎
};

This PR extends each Scalar to have input and output:

export type Scalars = {
  ID: {
    input: string | number;
    output: string;
  };
};

Then, each input/output GraphQL type can correctly refer to the correct input/output scalar type:

export type Book = {
  __typename?: 'Book';
  id: Scalars['ID']['output']; // Output's ID can be `string` 👍
};

export type QueryBookArgs = {
  id: Scalars['ID']['input']; // Input's ID can be `string` or `number` 👍
};

Note that for typescript-resolvers, the type of ID needs to be inverted. However, the referenced types in GraphQL input/output types should still work correctly:

export type Scalars = {
  ID: {
    input: string;
    output: string | number;
  }
}

export type Book = {
  __typename?: "Book";
  id: Scalars["ID"]['output']; // Resolvers can return `string` or `number` in ID fields 👍
};

export type QueryBookArgs = {
  id: Scalars["ID"]['input']; // Resolvers receive `string` in ID fields 👍
};

export type ResolversTypes = {
  ID: ID: ResolverTypeWrapper<Scalars['ID']['output']>; // Resolvers can return `string` or `number` in ID fields 👍
}

export type ResolversParentTypes = {
  ID: Scalars['ID']['output']; // Resolvers receive `string` or `number` from parents 👍
};

Config changes:

Scalars option can now take input/output types:

config: {
  scalars: {
    ID: {
      input: 'string',
      output: 'string | number'
    }
  }
}

If a string is given (instead of an object with input/output fields), it will be used as both input and output types:

config: {
  scalars: {
    ID: 'string'; // This means `string` will be used for both ID's input and output types
  }
}

BREAKING CHANGE: External module Scalar types need to be an object with input/output fields

config: {
  scalars: {
    ID: './path/to/scalar-module';
  }
}

If correctly, wired up, the following will be generated:

// Previously, imported `ID` type can be a primitive type, now it must be an object with input/output fields
import { ID } from './path/to/scalar-module';

export type Scalars = {
  ID: { input: ID['input']; output: ID['output'] };
};

BREAKING CHANGE: This changes Scalar types which could be referenced in other plugins. If you are a plugin maintainer and reference Scalar, please update your plugin to use the correct input/output types.

bb66c2a31 Thanks @n1ru4l! - Require Node.js >= 16. Drop support for Node.js 14

Minor Changes

#9196 3848a2b73 Thanks @beerose! - Add @defer directive support

When a query includes a deferred fragment field, the server will return a partial response with the non-deferred fields first, followed by the remaining fields once they have been resolved.

Once start using the @defer directive in your queries, the generated code will automatically include support for the directive.

// src/index.tsx
import { graphql } from './gql';
const OrdersFragment = graphql(`
  fragment OrdersFragment on User {
    orders {
      id
      total
    }
  }
`);
const GetUserQuery = graphql(`
  query GetUser($id: ID!) {
    user(id: $id) {
      id
      name
      ...OrdersFragment @&#8203;defer
    }
  }
`);

The generated type for GetUserQuery will have information that the fragment is incremental, meaning it may not be available right away.

// gql/graphql.ts
export type GetUserQuery = { __typename?: 'Query'; id: string; name: string } & ({
  __typename?: 'Query';
} & {
  ' $fragmentRefs'?: { OrdersFragment: Incremental<OrdersFragment> };
});

Apart from generating code that includes support for the @defer directive, the Codegen also exports a utility function called isFragmentReady. You can use it to conditionally render components based on whether the data for a deferred
fragment is available:

const OrdersList = (props: { data: FragmentType<typeof OrdersFragment> }) => {
  const data = useFragment(OrdersFragment, props.data);
  return (
    // render orders list
  )
};

function App() {
  const { data } = useQuery(GetUserQuery);
  return (
    {data && (
      <>
        {isFragmentReady(GetUserQuery, OrdersFragment, data)
					&& <OrdersList data={data} />}
      </>
    )}
  );
}
export default App;