Seeking Codegen feedback

[trevor-scheer]

I'd like to remove codegen completely in an upcoming major release of the CLI. For awhile, graphql-code-generator has been a superior tool which offers compatibility with all of Apollo's tools. We highly recommend migrating to it.

For anyone who is still using Apollo's codegen feature, is there anything in particular that's prevented you from making the switch?

[gabrielcsapo]

I just used https://www.graphql-code-generator.com/ lots of configuration options and really easy to use. I really enjoyed it.

[dotansimha]

Also related: #2053 :)

[trevor-scheer]

@dotansimha thanks for that fantastic writeup, I'm sorry we never went forward with any of the suggestions you laid out. It certainly wasn't for a lack of effort on your part - as I'm sure you can tell this repo has gone unloved for some time now. 2 years ago, the idea of wrapping graphql-code-generator might've been appealing, but at this point we're actively trying to push users away from the CLI (in most cases, when possible, excluding a few client:* commands which aren't yet supported by rover).

I'm going to leave #2053 open for now since there's a lot of great information there for people looking to migrate, in hopes that it's slightly more discoverable open instead of closed. You're more than welcome to close it if you choose, I'll probably close whenever I finally get to cut the last major for these packages.

[markhalonen]

I considered switching to graphql-code-generator but I stayed with Apollo's version because it generates intermediate types, which I use extensively. The solution proposed in #2053 (comment) is to use Fragments, which makes sense if the Fragment is used multiple times, but often I want to use the intermediate type(s) on regular Queries with no Fragments.

Having to insert Fragments into my Query just to get the intermediate types to generate is not ideal, it makes the Query more complex, and I have to name the Fragment.

[n1ru4l]

@markhalonen can you share your use-case for accessing indermediate types? We did this in codegen V1, but decided to drop it as it bloated auto-complete suggestions and code output with named types. As an alternative you can use lookup types.

[dotansimha]

hi @markhalonen ! As @n1ru4l said, we had the in older versions of codegen, but we decided to drop it (~4y ago. there's still typescript-compatibility plugin that will generate intermediate types for you, but it does not support all plugins features).

The main reason was the complexity of the generated output and the fact that it led to many conflicts and unused types.
Fragments + ad-hoc lookup types should solve that for you and make it simpler to access nested/shared fieldsets.
I can understand how hard the process of moving a codebase that depends heavily on these types might be, but from our experience with many GraphQL projects, it is worth it.
Features like TypedDocumentNode makes the client-side code so much simpler and clean, we have large projects that don't even need to use lookup types that much, since fragments and type inference cover most of the needs.

[markhalonen]

can you share your use-case for accessing intermediate types?

For example I'd import a type such as

import {
PartNumberProcessQuery_partNumberById_processNodeByDefaultProcessNodeId_descendantRelationships_processNodeByFromId as ProcessNodeWithDetails,
} from '../generated'

and then parse a tree into an ordered flat list of these Nodes, and then pass that flat list to a child component.

ad-hoc lookup types should solve that for you

Ah, I looked that up. I've never used lookup types before. Wow, TypeScript is powerful! That would be a solution for intermediate types.

Well, especially with the Apollo maintainers advocating for graphql-code-generator it seems a migration is in my future... Thanks for the tips guys!