@ts-gql/[email protected]

Patch Changes

• #121 f71eef0 Thanks @emmatown! - Add generated output types back to @schema.d.ts

@ts-gql/[email protected]

Minor Changes

• #117 9cc5227 Thanks @emmatown! - Support typescript-eslint@6

@ts-gql/[email protected]

Patch Changes

• f5e7421 Thanks @emmatown! - Fix linting files with array destructuring that ignore elements like [,something]

@ts-gql/[email protected]

Patch Changes

• 08e1a62 Thanks @emmatown! - Fixes duplicate fragments in document export of generated files

@ts-gql/[email protected]

Patch Changes

• 57d5d10 Thanks @emmatown! - Fix enums not being exported by @Schema

@ts-gql/[email protected]

Patch Changes

• #106 69b71e4 Thanks @mitchellhamilton! - Built-in scalars that haven't been overriden in the scalars config will now be inlined when generating the schema input types rather than referencing the generated Scalars type (which should not be imported outside of ts-gql's generated files).

@ts-gql/[email protected]

Patch Changes

• Updated dependencies [ec3330f, 11d562a, 11d562a]:
  • @ts-gql/[email protected]

@ts-gql/[email protected]

Minor Changes

• #105 11d562a Thanks @mitchellhamilton! - TypeScript types for object, union and interface types are no longer generated in __generated__/ts-gql/@schema.d.ts. These types have an unclear meaning and were not intended to be used. If you relied on these types, you may want to use GraphQL Code Generator to generate those types for you.

• #105 11d562a Thanks @mitchellhamilton! - The correct types are now generated to account for list input coercion in input object types(the correct types were already generated for variables) so for example, given an input object like:

  input SomeInput {
    ids: [ID!]!
  }

  The generated TypeScript type will now be equivelent to this:

  export type SomeInput = {
    ids: string | string[];
  };

  instead of what it was previously:

  export type SomeInput = {
    ids: string[];
  };

Patch Changes

• #102 ec3330f Thanks @mitchellhamilton! - Fixed custom scalar types not being respected in output types

@ts-gql/[email protected]

Patch Changes

• #100 63d269d Thanks @mitchellhamilton! - Fixed incorrect fix/error for casts on gql calls in source files in the same directory as the config.

@ts-gql/[email protected]

Minor Changes

• #98 bc8d6eb Thanks @mitchellhamilton! - ts-gql's TypedDocumentNode type is now compatible with @graphql-typed-document-node/core's TypedDocumentNode.

  The recommended usage of ts-gql with Apollo Client is now to use @apollo/client directly. This also allows ts-gql to be used with urql and any other GraphQL client that supports @graphql-typed-document-node/core. The @ts-gql/apollo package can still be used and may be updated in the future to avoid breakage if that makes sense but it is no longer the recommended pattern.

  When using @apollo/client over @ts-gql/apollo, it's important to note that some type safety will be lost:

  • Variables are always optional so omitting variables when they are required will no longer be caught by TypeScript
  • refetchQueries will accept any string so passing names to queries that don't exist will not cause a TypeScript error. You should likely pass in the document with the query itself to avoid mis-typing query names causing errors.

  Because @graphql-typed-document-node/core's TypedDocumentNode extends graphql's DocumentNode, this means that getDocumentNode from @ts-gql/tag is no longer necessary. This could be another cause for bugs if there are two APIs, one that accepts a TypedDocumentNode that you should use and another that accepts DocumentNode which you shouldn't use, you could accidentally use the API that accepts DocumentNode over the one that accepts TypedDocumentNode where previously you would get an error when passing a TypedDocumentNode to something accepting a DocumentNode.

  Context behind this change

  When ts-gql was originally written, @graphql-typed-document-node/core did not exist. Since then, @graphql-typed-document-node/core has become used by Apollo Client and urql. Given that, maintaining types to adapt Apollo Client to ts-gql's TypedDocumentNode seems less sensible.

  While this does mean that some of ts-gql's safety is reduced, this seems like an appropriate trade-off so that ts-gql can reduce maintaince burden, avoid imposing opinions on top of GraphQL clients and support more GraphQL clients without having to write types for them specifically.