Apollo v4 CodeGen Broken w/o config Overrides

[ksylvest]

Which packages are impacted by your issue?

@graphql-codegen/typescript-react-apollo

Describe the bug

When using @graphql-codegen with the typescript-react-apollo plugin and @apollo/client v4 the generated code is invalid. Generated hooks (e.g. useQuery / useMutation) must be imported from @apollo/client/react, but are imported through @apollo/client. This causes a generated file to compile.

A workaround is to manually specify the following in the codegen.ts file:

config: {
  apolloReactCommonImportFrom: "@apollo/client/react",
  apolloReactHooksImportFrom: "@apollo/client/react",
}

Your Example Website or App

N/A

Steps to Reproduce the Bug or Issue

1. Bump @apollo/client from v3 to v4
2. Run codegen
3. Build the generated code.

Expected behavior

The file does not compile and it is expected to compile.

Screenshots or Videos

No response

Platform

• OS: macOS
• NodeJS: v24

Codegen Config File

No response

Additional context

No response

[mchoraine]

Hello !
I encountered the same issue after upgrading to apollo v4 but I haven't succeed to resolve it like you describe.
I got some other types with invalid import after code generation.

Type error: Namespace '"./node_modules/@apollo/client/react/index"' has no exported member 'MutationFunction'.

@ksylvest did you succeed to solve it ? Thanks

I really hope that a new version of the plugin will be release soon :)

[ksylvest]

@mchoraine I hadn't tested w/ a schema containing mutations. I just re-tested you are correct those types don't appear to exist anymore. I'm not sure how to solve.

[vriesr032]

Has anyone picked this up already? Bump @apollo/client from v3 to v4

Otherwise I can maybe take a look

[Netail]

Hello ! I encountered the same issue after upgrading to apollo v4 but I haven't succeed to resolve it like you describe. I got some other types with invalid import after code generation.

Type error: Namespace '"./node_modules/@apollo/client/react/index"' has no exported member 'MutationFunction'.

@ksylvest did you succeed to solve it ? Thanks

I really hope that a new version of the plugin will be release soon :)

Query types have been moved into type namespaces; https://www.apollographql.com/docs/react/migrating/apollo-client-4-migration#namespaced-types

MutationFunction should be located in the useMutation namespace, you could try useMutation.MutationFunction.

[eddeee888]

Hi all 👋

Apollo Client v4 and generated hooks incompatibility goes beyond type renames. v4 introduces lots of type overloads that do NOT work with generated hooks, creating a real risk of runtime errors in production.

You can see an example of wrong type inference here.

Apollo team recommends against using generated hooks for this reason.

We (Codegen team) recommend migrating to Client Preset instead of relying generated hooks. We will deprecate typescript-react-apollo plugin soon.

Here's a codemod that you could use for migration: https://www.npmjs.com/package/@eddeee888/gcg-operation-location-migration . Please let me know if you have any issues.

• Blog post: https://the-guild.dev/graphql/hive/blog/graphql-codemod-use-case-migrating-from-apollo-client-generated-hooks-to-client-preset
• Video: https://www.youtube.com/watch?v=GGmt0hvnQNU

[EvgeniyKumachev]

I don't think my team would be glad to review few thousand lines of changes with migration from codegen to client preset 😅.

In my case bundle size and strictness of dataState property isn't really an issue. Wouldn't want to stockpile techdebt either so would be nice to have some stopgap option where it generates with uncertain dataState. I'll try to look into it in spare time

[EvgeniyKumachev]

Logic for visitor.ts doesn't seem that hard to upgrade, i've mostly updated it to support v4
https://gist.github.com/EvgeniyKumachev/c65fdd9092b1a1d09132f700774c238e

Since in v4 they removed hocs and components options for them should probably be deprecated or removed but i'm not sure about deprecating them myself

[eddeee888]

Hi @EvgeniyKumachev ,

I appreciate the time you put into trying to fix this. 🙂

I don't think my team would be glad to review few thousand lines of changes with migration from codegen to client preset 😅.

I totally understand the concern, I highly recommend doing this in multiple PRs.
You can target where you'd like to run the migrations by changing a generates blocks' key. Hopefully, there are tests in place to catch potential errors.

In my case bundle size and strictness of dataState property isn't really an issue. Wouldn't want to stockpile techdebt either so would be nice to have some stopgap option where it generates with uncertain dataState

Unfortunately, we cannot enforce this expectation for all users 😕
I'd say the stopgap is the incremental codemod approach mentioned above.

[EvgeniyKumachev]

Hi @EvgeniyKumachev ,

I appreciate the time you put into trying to fix this. 🙂

I don't think my team would be glad to review few thousand lines of changes with migration from codegen to client preset 😅.

I totally understand the concern, I highly recommend doing this in multiple PRs. You can target where you'd like to run the migrations by changing a generates blocks' key. Hopefully, there are tests in place to catch potential errors.

In my case bundle size and strictness of dataState property isn't really an issue. Wouldn't want to stockpile techdebt either so would be nice to have some stopgap option where it generates with uncertain dataState

Unfortunately, we cannot enforce this expectation for all users 😕 I'd say the stopgap is the incremental codemod approach mentioned above.

Got it, thanks. I'll make a separate fork then with support for v4 as described above. Sadly i can't justify to my PM refactor of the whole codebase to support strict typing of one property that we don't even use

[AELSchauer]

Hey all! If your repo is using typescript and react, I've found that it's unnecessary to run the migration script from @eddeee888.
His script will copy your GraphQL queries into you components. However, you can access those from the gql/graphql.ts file generated by the client-preset. This is a pretty good guide to understand client-preset.

Here's what I did instead.

// codegen.ts
// I kept both generated files so I could incrementally migrate my files. When I'm ready to migrate to v4, I'll remove the original.

const config: CodegenConfig = {
  ...
  ignoreNoDocuments: true,
  generates: {
    ["./app/generated.ts"]: { // This is my original file that is generating the QueryHooks
      plugins: [
        "typescript",
        "typescript-operations",
        "typescript-react-apollo",
        "named-operations-object",
      ],
    },
    "./app/gql/": { // These is my new generated files.
      preset: "client",
      presetConfig: {
        fragmentMasking: false,
      },
    },
  },
  ...
}

// SupportBanner.tsx

import {
  BannerPreferencesDocument,
  BannerPreferencesQuery,
  DismissSupportBannerDocument,
  DismissSupportBannerMutation,
  SupportPreferenceCategoryEnum,
} from "gql/graphql";

const SupportBanner: React.FC<SupportBannerProps> = ({
  topic,
  ...viewProps
}): React.ReactElement | null => {
  const { data, error, loading } = useQuery<BannerPreferencesQuery>(
    BannerPreferencesDocument,
  );
  const [dismissBanner] = useMutation<DismissSupportBannerMutation>(
    DismissSupportBannerDocument,
  );

[vitexikora]

Oh no! Seems like our huge codebase is now stuck at Apollo v3 :(
The static hook generation is a massively integral part of our app. We have also developed a schema versioning system with static assurence above it, to ensure our 30+ projects always run with compatible API.
All our GQL documents are in own .gql files. This sped up intellisense speed a lot, not having to parse gql from ts files. We have a huge schema. It was a big migration, I am definitely not going back.
What would it take for codegen to support Apollo v4? We might consider forking it.

[eddeee888]

Hi @vitexikora ,
I'm curious about the performance issue you mention:

This sped up intellisense speed a lot, not having to parse gql from ts files

May I know if you were using Client Preset when you see this issue?
If so, could you please elaborate which part of intellisense speed was impacted? The document node type? Codegen run duration ? Or something else?

What would it take for codegen to support Apollo v4? We might consider forking it.

I can't think of a way to preserve Apollo Client's type overloads using the generated hooks approach.
Note that dataState type overload is one example introduced in v4, and there could be more that I'm not aware of, and may increase in the future

i.e. the effort to maintain type correctness for generated hooks would increase exponentially