Skip to content

Latest commit

 

History

History
1209 lines (818 loc) · 42.5 KB

File metadata and controls

1209 lines (818 loc) · 42.5 KB

@graphql-codegen/visitor-plugin-common

4.0.1

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.

4.0.0

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:

    1. Scalars option can now take input/output types:
    config: {
      scalars: {
        ID: {
          input: 'string',
          output: 'string | number'
        }
      }
    }
    1. 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
      }
    }
    1. 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 @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;
  • #9339 50471e651 Thanks @AaronMoat! - Add excludeTypes config to resolversNonOptionalTypename

    This disables the adding of __typename in resolver types for any specified typename. This could be useful e.g. if you're wanting to enable this for all new types going forward but not do a big migration.

    Usage example:

    const config: CodegenConfig = {
      schema: 'src/schema/**/*.graphql',
      generates: {
        'src/schema/types.ts': {
          plugins: ['typescript', 'typescript-resolvers'],
          config: {
            resolversNonOptionalTypename: {
              unionMember: true,
              excludeTypes: ['MyType'],
            },
          },
        },
      },
    };
  • #9229 5aa95aa96 Thanks @eddeee888! - Use generic to simplify ResolversUnionTypes

    This follows the ResolversInterfaceTypes's approach where the RefType generic is used to refer back to ResolversTypes or ResolversParentTypes in cases of nested Union types

  • #9304 e1dc75f3c Thanks @esfomeado! - Added support for disabling suffixes on Enums.

  • #9229 5aa95aa96 Thanks @eddeee888! - Extract interfaces to ResolversInterfaceTypes and add to resolversNonOptionalTypename

    1. ResolversInterfaceTypes is a new type that keeps track of a GraphQL interface and its implementing types.

    For example, consider this schema:

    extend type Query {
      character(id: ID!): CharacterNode
    }
    
    interface CharacterNode {
      id: ID!
    }
    
    type Wizard implements CharacterNode {
      id: ID!
      screenName: String!
      spells: [String!]!
    }
    
    type Fighter implements CharacterNode {
      id: ID!
      screenName: String!
      powerLevel: Int!
    }

    The generated types will look like this:

    export type ResolversInterfaceTypes<RefType extends Record<string, unknown>> = {
      CharacterNode: Fighter | Wizard;
    };
    
    export type ResolversTypes = {
      // other types...
      CharacterNode: ResolverTypeWrapper<ResolversInterfaceTypes<ResolversTypes>['CharacterNode']>;
      Fighter: ResolverTypeWrapper<Fighter>;
      Wizard: ResolverTypeWrapper<Wizard>;
      // other types...
    };
    
    export type ResolversParentTypes = {
      // other types...
      CharacterNode: ResolversInterfaceTypes<ResolversParentTypes>['CharacterNode'];
      Fighter: Fighter;
      Wizard: Wizard;
      // other types...
    };

    The RefType generic is used to reference back to ResolversTypes and ResolversParentTypes in some cases such as field returning a Union.

    1. resolversNonOptionalTypename also affects ResolversInterfaceTypes

    Using the schema above, if we use resolversNonOptionalTypename option:

    const config: CodegenConfig = {
      schema: 'src/schema/**/*.graphql',
      generates: {
        'src/schema/types.ts': {
          plugins: ['typescript', 'typescript-resolvers'],
          config: {
            resolversNonOptionalTypename: true, // Or `resolversNonOptionalTypename: { interfaceImplementingType: true }`
          },
        },
      },
    };

    Then, the generated type looks like this:

    export type ResolversInterfaceTypes<RefType extends Record<string, unknown>> = {
      CharacterNode: (Fighter & { __typename: 'Fighter' }) | (Wizard & { __typename: 'Wizard' });
    };
    
    export type ResolversTypes = {
      // other types...
      CharacterNode: ResolverTypeWrapper<ResolversInterfaceTypes<ResolversTypes>['CharacterNode']>;
      Fighter: ResolverTypeWrapper<Fighter>;
      Wizard: ResolverTypeWrapper<Wizard>;
      // other types...
    };
    
    export type ResolversParentTypes = {
      // other types...
      CharacterNode: ResolversInterfaceTypes<ResolversParentTypes>['CharacterNode'];
      Fighter: Fighter;
      Wizard: Wizard;
      // other types...
    };

Patch Changes

3.1.1

Patch Changes

3.1.0

Minor Changes

  • #9146 9f4d9c5a4 Thanks @eddeee888! - [typescript-resolvers] Add resolversNonOptionalTypename config option.

    This is extending on ResolversUnionTypes implemented in #9069

    resolversNonOptionalTypename adds non-optional __typename to union members of ResolversUnionTypes, without affecting the union members' base intefaces.

    A common use case for non-optional __typename of union members is using it as the common field to work out the final schema type. This makes implementing the union's __resolveType very simple as we can use __typename to decide which union member the resolved object is. Without this, we have to check the existence of field/s on the incoming object which could be verbose.

    For example, consider this schema:

    type Query {
      book(id: ID!): BookPayload!
    }
    
    type Book {
      id: ID!
      isbn: String!
    }
    
    type BookResult {
      node: Book
    }
    
    type PayloadError {
      message: String!
    }
    
    union BookPayload = BookResult | PayloadError

    With optional __typename: We need to check existence of certain fields to resolve type in the union resolver:

    // Query/book.ts
    export const book = async () => {
      try {
        const book = await fetchBook();
        // 1. No `__typename` in resolver results...
        return {
          node: book,
        };
      } catch (e) {
        return {
          message: 'Failed to fetch book',
        };
      }
    };
    
    // BookPayload.ts
    export const BookPayload = {
      __resolveType: parent => {
        // 2. ... means more checks in `__resolveType`
        if ('message' in parent) {
          return 'PayloadError';
        }
        return 'BookResult';
      },
    };

    With non-optional __typename: Resolvers declare the type. This which gives us better TypeScript support in resolvers and simplify __resolveType implementation:

    // Query/book.ts
    export const book = async () => {
      try {
        const book = await fetchBook();
        // 1. `__typename` is declared in resolver results...
        return {
          __typename: 'BookResult', // 1a. this also types `node` for us 🎉
          node: book,
        };
      } catch (e) {
        return {
          __typename: 'PayloadError',
          message: 'Failed to fetch book',
        };
      }
    };
    
    // BookPayload.ts
    export const BookPayload = {
      __resolveType: parent => parent.__typename, // 2. ... means a very simple check in `__resolveType`
    };

    Using resolversNonOptionalTypename: add it into typescript-resolvers plugin config:

    // codegen.ts
    const config: CodegenConfig = {
      schema: 'src/schema/**/*.graphql',
      generates: {
        'src/schema/types.ts': {
          plugins: ['typescript', 'typescript-resolvers'],
          config: {
            resolversNonOptionalTypename: true, // Or `resolversNonOptionalTypename: { unionMember: true }`
          },
        },
      },
    };

Patch Changes

  • #9206 e56790104 Thanks @eddeee888! - Fix ResolversUnionTypes being used in ResolversParentTypes

    Previously, objects with mappable fields are converted to Omit format that references its own type group or ResolversTypes or ResolversParentTypes e.g.

    export type ResolversTypes = {
      Book: ResolverTypeWrapper<BookMapper>;
      BookPayload: ResolversTypes['BookResult'] | ResolversTypes['StandardError'];
      // Note: `result` on the next line references `ResolversTypes["Book"]`
      BookResult: ResolverTypeWrapper<Omit<BookResult, 'result'> & { result?: Maybe<ResolversTypes['Book']> }>;
      StandardError: ResolverTypeWrapper<StandardError>;
    };
    
    export type ResolversParentTypes = {
      Book: BookMapper;
      BookPayload: ResolversParentTypes['BookResult'] | ResolversParentTypes['StandardError'];
      // Note: `result` on the next line references `ResolversParentTypes["Book"]`
      BookResult: Omit<BookResult, 'result'> & { result?: Maybe<ResolversParentTypes['Book']> };
      StandardError: StandardError;
    };

    In #9069, we extracted resolver union types to its own group:

    export type ResolversUnionTypes = {
      // Note: `result` on the next line references `ResolversTypes["Book"]` which is only correct for the `ResolversTypes` case
      BookPayload: (Omit<BookResult, 'result'> & { result?: Maybe<ResolversTypes['Book']> }) | StandardError;
    };
    
    export type ResolversTypes = {
      Book: ResolverTypeWrapper<BookMapper>;
      BookPayload: ResolverTypeWrapper<ResolversUnionTypes['BookPayload']>;
      BookResult: ResolverTypeWrapper<Omit<BookResult, 'result'> & { result?: Maybe<ResolversTypes['Book']> }>;
      StandardError: ResolverTypeWrapper<StandardError>;
    };
    
    export type ResolversParentTypes = {
      Book: BookMapper;
      BookPayload: ResolversUnionTypes['BookPayload'];
      BookResult: Omit<BookResult, 'result'> & { result?: Maybe<ResolversParentTypes['Book']> };
      StandardError: StandardError;
    };

    This change creates an extra ResolversUnionParentTypes that is referenced by ResolversParentTypes to ensure backwards compatibility:

    export type ResolversUnionTypes = {
      BookPayload: (Omit<BookResult, 'result'> & { result?: Maybe<ResolversParentTypes['Book']> }) | StandardError;
    };
    
    // ... and the reference is changed in ResolversParentTypes:
    export type ResolversParentTypes = {
      // ... other fields
      BookPayload: ResolversUnionParentTypes['BookPayload'];
    };
  • #9194 acb647e4e Thanks @dstaley! - Don't emit import statements for unused fragments

  • Updated dependencies [b7dacb21f, f104619ac]:

    • @graphql-codegen/plugin-helpers@4.2.0

3.0.2

Patch Changes

3.0.1

Patch Changes

3.0.0

Major Changes

Patch Changes

2.13.8

Patch Changes

  • #8816 a98198524 Thanks @charle692! - Fix issue where visitor-plugin-common emitted ESM imports for Operations when emitLegacyCommonJSImports is true

2.13.7

Patch Changes

2.13.6

Patch Changes

2.13.5

Patch Changes

  • 46f75304a Thanks @saihaj! - fix the version of @graphql-codegen/plugin-helpers@3.1.1

  • Updated dependencies [307a5d350]:

    • @graphql-codegen/plugin-helpers@3.1.1

2.13.4

Patch Changes

2.13.3

Patch Changes

2.13.2

Patch Changes

  • #8586 ef4c2c9c2 Thanks @levrik! - Fix incompatibility between @oneOf input types and declaration kind other than type

2.13.1

Patch Changes

2.13.0

Minor Changes

2.12.2

Patch Changes

2.12.1

Patch Changes

2.12.0

Minor Changes

  • 2cbcbb371: Add new flag to emit legacy common js imports. Default it will be true this way it ensure that generated code works with non-compliant bundlers.

    You can use the option in your config:

    schema: 'schema.graphql'
     documents:
       - 'src/**/*.graphql'
     emitLegacyCommonJSImports: true

    Alternative you can use the CLI to set this option:

    $ codegen --config-file=config.yml --emit-legacy-common-js-imports

Patch Changes

  • Updated dependencies [2cbcbb371]
    • @graphql-codegen/plugin-helpers@2.6.0

2.11.1

Patch Changes

  • 525ad580b: Revert breaking change for Next.js applications that are incapable of resolving an import with a .js extension.

2.11.0

Minor Changes

Patch Changes

  • Updated dependencies [d84afec09]
  • Updated dependencies [a4fe5006b]
  • Updated dependencies [8e44df58b]
    • @graphql-codegen/plugin-helpers@2.5.0

2.10.0

Minor Changes

  • aa1e6eafd: Add @Deprecated support for input

Patch Changes

  • a42fcbfe4: docs: Swapping rootValueType with directiveContextTypes for correctness
  • 8b10f22be: Ensure falsy enum values are still mapped

2.9.1

Patch Changes

  • d16bebacb: Update @graphql-tools/relay-operation-optimizer package;

    • Previously that package used relay-compiler@12 which has graphql v15 as a peer dependency and it was causing peer dependency warnings if user installs a different version of graphql package. Now we forked and released v12 under a different name and removed version range for graphql in peerDependencies of relay-compiler

2.9.0

Minor Changes

  • c3d7b7226: support the @oneOf directive on input types.

2.8.0

Minor Changes

  • f1fb77bd4: feat: Add option to squash exactly similar fragment types

2.7.6

Patch Changes

  • 9a5f31cb6: New option onlyEnums for Typescript

2.7.5

Patch Changes

  • 2966686e9: Generate $fragmentName for fragment subtypes for fragment masking

2.7.4

Patch Changes

  • 337fd4f77: WP: [typescript-resolvers] Add directiveContextTypes option

2.7.3

Patch Changes

  • 54718c039: Improve @Deprecated Enum Type developer experience

2.7.2

Patch Changes

  • 11d05e361: fix(resolvers): fix conflict between typesPrefix: true and enumPrefix: false

2.7.1

Patch Changes

  • fd55e2039: fix incorrect type generation when using the inlineFragmentTypes 'combine' option that resulted in generating masked fragment output.

2.7.0

Minor Changes

  • 1479233df: Add new inlineFragmentTypes mode 'mask', which allows generating masked fragment types.

2.6.0

Minor Changes

  • bef4376d5: fix: RequireFields generic making all other fields optional

Patch Changes

  • c8ef37ae0: fix(typescript-resolvers): Fix optional field types
  • be7cb3a82: Performance work: resolvers plugins, documents loading
  • Updated dependencies [754a33715]
    • @graphql-codegen/plugin-helpers@2.4.0

2.5.2

Patch Changes

  • 6002feb3d: Fix exports in package.json files for react-native projects
  • Updated dependencies [6002feb3d]
    • @graphql-codegen/plugin-helpers@2.3.2

2.5.1

Patch Changes

  • a9f1f1594: Use maybeValue as default output for optionals on preResolveTypes: true
  • 9ea6621ec: add missing ListType method parameters

2.5.0

Minor Changes

  • 97ddb487a: feat: GraphQL v16 compatibility

Patch Changes

  • Updated dependencies [97ddb487a]
    • @graphql-codegen/plugin-helpers@2.3.0

2.4.0

Minor Changes

  • ad02cb9b8: Fixed an issue where ResolversParentTypes referenced non-existing fields of ResolversParentTypes when the corresponding type was a mapped enum.

2.3.0

Minor Changes

  • b9e85adae: feat(visitor-plugin-common): support custom scalar type from extensions

Patch Changes

  • 3c2c847be: Fix dedupleFragments option for typescript-react-query (and possibly others)
  • Updated dependencies [7c60e5acc]
    • @graphql-codegen/plugin-helpers@2.2.0

2.2.1

Patch Changes

  • 0b090e31a: Apply proper indentation to DirectiveArgs types

2.2.0

Minor Changes

  • d6c2d4c09: Allow declaring Argument and InputType field mappings based on directive annotations.

    WARNING: Using this option does only change the type definitions.

    For actually ensuring that a type is correct at runtime you will have to use schema transforms (e.g. with @graphql-tools/utils mapSchema) that apply those rules! Otherwise, you might end up with a runtime type mismatch which could cause unnoticed bugs or runtime errors.

    Please use this configuration option with care!

    plugins:
      config:
        directiveArgumentAndInputFieldMappings:
          asNumber: number
    directive @asNumber on ARGUMENT_DEFINITION | INPUT_FIELD_DEFINITION
    
    input MyInput {
      id: ID! @asNumber
    }
    
    type User {
      id: ID!
    }
    
    type Query {
      user(id: ID! @asNumber): User
    }

    Usage e.g. with typescript-resolvers

    const Query: QueryResolvers = {
      user(_, args) {
        // args.id is of type 'number'
      },
    };
  • 5086791ac: Allow overwriting the resolver type signature based on directive usages.

    WARNING: Using this option does only change the generated type definitions.

    For actually ensuring that a type is correct at runtime you will have to use schema transforms (e.g. with @graphql-tools/utils mapSchema) that apply those rules! Otherwise, you might end up with a runtime type mismatch which could cause unnoticed bugs or runtime errors.

    Example configuration:

    config:
      # This was possible before
      customResolverFn: ../resolver-types.ts#UnauthenticatedResolver
      # This is new
      directiveResolverMappings:
        authenticated: ../resolvers-types.ts#AuthenticatedResolver

    Example mapping file (resolver-types.ts):

    export type UnauthenticatedContext = {
      user: null;
    };
    
    export type AuthenticatedContext = {
      user: { id: string };
    };
    
    export type UnauthenticatedResolver<TResult, TParent, _TContext, TArgs> = (
      parent: TParent,
      args: TArgs,
      context: UnauthenticatedContext,
      info: GraphQLResolveInfo
    ) => Promise<TResult> | TResult;
    
    export type AuthenticatedResolver<TResult, TParent, _TContext, TArgs> = (
      parent: TParent,
      args: TArgs,
      context: AuthenticatedContext,
      info: GraphQLResolveInfo
    ) => Promise<TResult> | TResult;

    Example Schema:

    directive @authenticated on FIELD_DEFINITION
    
    type Query {
      yee: String
      foo: String @authenticated
    }

Patch Changes

  • feeae1c66: Do not throw an error when trying to merge inline fragment usages.

2.1.2

Patch Changes

  • 6470e6cc9: fix(plugin-helpers): remove unnecessary import
  • 263570e50: Don't generate duplicate imports for the same identifier
  • Updated dependencies [6470e6cc9]
  • Updated dependencies [35199dedf]
    • @graphql-codegen/plugin-helpers@2.1.1

2.1.1

Patch Changes

  • aabeff181: Don't generate import statements for fragments declared in the file we're outputting to

2.1.0

Minor Changes

  • 290170262: add getOperationVariableName function to ClientSideBasePluginConfig class
  • 440172cfe: support ESM

Patch Changes

  • 24185985a: bump graphql-tools package versions
  • Updated dependencies [24185985a]
  • Updated dependencies [39773f59b]
  • Updated dependencies [440172cfe]
    • @graphql-codegen/plugin-helpers@2.1.0

2.0.0

Major Changes

  • d80efdec4: Change preResolveTypes default to be true for more readable types

  • b0cb13df4: Update to latest graphql-tools and graphql-config version.

    ‼️ ‼️ ‼️ Please note ‼️ ‼️ ‼️:

    This is a breaking change since Node 10 is no longer supported in graphql-tools, and also no longer supported for Codegen packages.

Patch Changes

  • d80efdec4: Add option inlineFragmentTypes for deep inlining fragment types within operation types. This inlineFragmentTypes is set to inline by default (Previous behaviour is combine).

    This behavior is the better default for users that only use Fragments for building operations and then want to have access to all the data via the operation type (instead of accessing slices of the data via fragments).

  • Updated dependencies [b0cb13df4]

    • @graphql-codegen/plugin-helpers@2.0.0

1.22.0

Minor Changes

  • 9005cc17: add allowEnumStringTypes option for allowing string literals as valid return types from resolvers in addition to enum values._

Patch Changes

  • df19a4ed: Allow multiple {T} instances in defaultMapper
  • Updated dependencies [470336a1]
    • @graphql-codegen/plugin-helpers@1.18.8

1.21.3

Patch Changes

  • 6762aff5: Fix for array types with @skip @include directives

1.21.2

Patch Changes

  • 6aaecf1c: Fix issues with missing sub-fragments when skipTypename: true

1.21.1

Patch Changes

  • cf1e5abc: Introduce new feature for removing duplicated fragments

1.21.0

Minor Changes

  • 8da7dff6: Skip typechecking on generated values by casting to unknown

Patch Changes

  • dfd25caf: chore(deps): bump graphql-tools versions
  • Updated dependencies [dfd25caf]
    • @graphql-codegen/plugin-helpers@1.18.7

1.20.0

Minor Changes

  • f0b5ea53: Add entireFieldWrapperValue configuration option, to wrap arrays
  • 097bea2f: Added new configuration settings for scalars: strictScalars and defaultScalarType

Patch Changes

  • d9212aa0: fix(visitor-plugin-common): guard for a runtime type error
  • Updated dependencies [d9212aa0]
    • @graphql-codegen/plugin-helpers@1.18.5

1.19.1

Patch Changes

  • 23862e7e: fix(naming-convention): revert and pin change-case-all dependency for workaround #3256
  • Updated dependencies [23862e7e]
    • @graphql-codegen/plugin-helpers@1.18.4

1.19.0

Minor Changes

  • d4942d04: NEW CONFIG (onlyResolveTypeForInterfaces): Allow to generate only __resolveType for interfaces

Patch Changes

  • e947f8e3: Allow to have declarationKind of type: class, interface: interface
  • 29b75b1e: enhance(docs): improve docs for naming convention
  • 1f6f3db6: Fix for @skip @include directives upon arrays
  • 29b75b1e: enhance(namingConvention): use change-case-all instead of individual packages for naming convention
  • Updated dependencies [29b75b1e]
    • @graphql-codegen/plugin-helpers@1.18.3

1.18.3

Patch Changes

  • 5749cb8a: chore: fix type-level incompatibilities of the avoidOptionals
  • 5a12fe58: fix type error on parsing enums

1.18.2

Patch Changes

  • ca66569f: Fix issues with undefined calls for str.replace

1.18.1

Patch Changes

  • 63be0f40: Fix issues with empty interfaces causing syntax issues
  • 190482a1: add support for fragment variables
  • 4444348d: Correctly escape enum values defined in the GraphQLSchema object
  • 142b32b3: Better support for @skip/@include directives with complex selection sets
  • 42213fa0: Strip trailing whitespace from some output

1.18.0

Minor Changes

  • bd4bf7cf: feat(visitor-plugin-common): add ignoreEnumValuesFromSchema to ignore enum values from GraphQLSchema

1.17.22

Patch Changes

  • 64293437: Support for input lists coercion
  • fd5843a7: Fixed a bug where some import namespacing is missed when generating resolver types.
  • d75051f5: generate correct types for fragments with an interface type condition that are spread on an interface field.

1.17.21

Patch Changes

  • 8356f8a2: Extended behaviour to allow support in internalResolversPrefix flag for resolvers plugin

1.17.20

Patch Changes

  • 1183d173: Bump all packages to resolve issues with shared dependencies
  • Updated dependencies [1183d173]
    • @graphql-codegen/plugin-helpers@1.18.2

1.17.19

Patch Changes

  • 99819bf1: Improve DocumentNode optimization for plugins that generate it
  • c3b59e81: Extract buildMapperImport to external function

1.17.18

Patch Changes

  • faa13973: Fixed a bug in parseMapper that were preventing to use mappers with complex type usages

1.17.17

Patch Changes

  • 612e5e52: remove broken isTypeOf call for expanding fragments with flattenGeneratedTypes = true
  • 9f2a4e2f: Expose _hasRequiredVariables to buildOperation in order to allow better type-safety for plugins that deals with variables
  • 0f35e775: Fix issues with incorrect naming of operation and variables when used with typesSuffix
  • Updated dependencies [eaf45d1f]
    • @graphql-codegen/plugin-helpers@1.18.1

1.17.16

Patch Changes

  • 92d8f876: Fixed unquoted numeric enum identifiers

1.17.15

Patch Changes

  • d2cde3d5: fixed isTypeOf resolvers signature
  • 89a6aa80: Fixes issues with typesSuffix and arguments type name
  • f603b8f8: Support unnamed queries in operation visitors
  • Updated dependencies [da8bdd17]
    • @graphql-codegen/plugin-helpers@1.17.9

1.17.14

Patch Changes

  • 07f9b1b2: Fix a bug caused numeric enum values defined in the GraphQLSchema to be printed incorrectly
  • 35f67120: bugfix: allow to specify mappers for GraphQL interface and override the default behaviour.

1.17.13

Patch Changes

  • 1d7c6432: Bump all packages to allow "^" in deps and fix compatibility issues
  • 1d7c6432: Bump versions of @graphql-tools/ packages to fix issues with loading schemas and SDL comments
  • Updated dependencies [1d7c6432]
  • Updated dependencies [1d7c6432]
    • @graphql-codegen/plugin-helpers@1.17.8

1.17.12

Patch Changes

  • 4266a15f: Allow getDocumentNodeSignature to control the entire generation flow of the typed documents

1.17.11

Patch Changes

  • ee2b01a3: Fixes for issues with publish command

1.17.10

Patch Changes

  • 6cb9c96d: Fixes issues with previous release

1.17.9

Patch Changes

  • bccfd28c: Allow to set gqlImport to a clean gql string and skip import generating

1.17.8

Patch Changes

  • ce3a5798: Publish minor version to include fixes for client-side-base-visitor, required to v2 of ts-react-apollo plugin (for unified apollo import)