Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix(deps): update graphqlcodegenerator monorepo (major) #8415

Closed
wants to merge 1 commit into from
Closed

fix(deps): update graphqlcodegenerator monorepo (major) #8415

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented May 25, 2023 •
edited
Loading

Mend Renovate logo banner

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@graphql-codegen/add 4.0.1 -> 5.0.0 age adoption passing confidence
@graphql-codegen/cli 3.3.1 -> 5.0.0 age adoption passing confidence
@graphql-codegen/core (source) 3.1.0 -> 4.0.0 age adoption passing confidence
@graphql-codegen/schema-ast 3.0.1 -> 4.0.0 age adoption passing confidence
@graphql-codegen/typescript 3.0.4 -> 4.0.1 age adoption passing confidence
@graphql-codegen/typescript-operations 3.0.4 -> 4.0.1 age adoption passing confidence
@graphql-codegen/typescript-react-apollo 3.3.7 -> 4.1.0 age adoption passing confidence
@graphql-codegen/typescript-resolvers 3.2.1 -> 4.0.1 age adoption passing confidence

Release Notes

dotansimha/graphql-code-generator (@​graphql-codegen/add)

v5.0.0

Compare Source

Major Changes
Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/cli)

v5.0.0

Compare Source

Major Changes
Patch Changes

v4.0.1

Compare Source

Patch Changes

v4.0.0

Compare Source

Major Changes
Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/core)

v4.0.0

Compare Source

Major Changes
Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/schema-ast)

v4.0.0

Compare Source

Major Changes
Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/typescript)

v4.0.1

Compare Source

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]:

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:

    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 @&#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;

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

Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/typescript-operations)

v4.0.1

Compare Source

Patch Changes

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:

    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 @&#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;

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

Patch Changes
dotansimha/graphql-code-generator-community (@​graphql-codegen/typescript-react-apollo)

v4.1.0

Compare Source

Minor Changes

v4.0.0

Compare Source

Major Changes
Patch Changes
dotansimha/graphql-code-generator (@​graphql-codegen/typescript-resolvers)

v4.0.1

Compare Source

Patch Changes

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:

    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 @&#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;

  • #​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

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot added the release:chore This PR is a chore (means nothing for users) label May 25, 2023
@renovate renovate bot assigned jtoar May 25, 2023
@replay-io
Copy link

replay-io bot commented May 25, 2023 •
edited
Loading

1 replays were recorded for 54ec343.

image 0 Failed
image 1 Passed

View test run on Replay ↗︎

@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 27 times, most recently from ecf0f1f to 86de8a5 Compare May 28, 2023 17:08
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch from 0bd123e to 9840a9d Compare July 8, 2023 03:19
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 5 times, most recently from 9a9a684 to e467368 Compare July 31, 2023 20:18
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 3 times, most recently from af58ffb to 28e271c Compare August 9, 2023 20:09
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 3 times, most recently from f710c6f to f3f352c Compare August 17, 2023 08:22
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 4 times, most recently from 2d6d61b to eda8d7e Compare August 31, 2023 18:03
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch from eda8d7e to aad48cb Compare September 1, 2023 23:10
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 3 times, most recently from 604f60e to 1a48045 Compare September 18, 2023 18:40
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 2 times, most recently from d12540d to 0b495ab Compare September 25, 2023 22:20
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch from 0b495ab to d961869 Compare October 16, 2023 11:53
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch from d961869 to f3a2489 Compare October 25, 2023 01:40
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch 3 times, most recently from da63644 to 9f3c821 Compare November 15, 2023 19:22
@renovate renovate bot force-pushed the renovate/major-graphqlcodegenerator-monorepo branch from 9f3c821 to 635c5ab Compare November 15, 2023 19:47
@jtoar jtoar closed this Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@jtoar jtoar

Labels
release:breaking This PR is a breaking change
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@jtoar