Codegen collaboration with Apollo Codegen and GraphQL Code Generator #2053
Comments
|
Thank you for this. I was interested in using hook generation and it looks like this is a good guide for me to migrate. |
|
@dotansimha one thing left out is the apollo option of |
|
What is this? We've been using apollo for years now, and I've never seen this naming convention used in output. |
|
Does the graphql codegen type names match apollo's? Located in file: I ask, because a significant deviation from this would hurt quite a bit. |
|
I've assessed transitioning, and TBH, I find Apollo's generated types/interfaces much simpler to reason about. Though I won't lie that I'm coming with a bias, based on years of use, and thousands of usages in our codebase. |
GraphQL Codegen doesn't generate intermediate types by default. There are solution, but in most cases just using fragments makes it simpler (and more correct in terms of GraphQL workflow).
You are right, maybe it was outdated :) But the point is that you can customize it.
Sure. I don't think there is a right/wrong choice here. It all depends on your workflow and what works best for you! |
|
@dotansimha Does |
With codegen, we recommend generated all types into a single file. When you want to generate more than one file (or, separate files based on operations/types), you can use |
see https://www.graphql-code-generator.com/docs/getting-started/codegen-config#environment-variables and https://www.graphql-code-generator.com/docs/getting-started/require-field#dotenv-integration |
|
@dotansimha Oh! totally missed that part, thank you! |
|
sorry, is not clear for me, how to generate this is my long road (and difficulties) to generate this types:
to a file that needs to be in the root folder (because in other location generate issues.) with all local schemas of all my resolvers
to this
and I don't know
|
|
One other thing not mentioned here is that apollo codegen can get really slow and I know that graphql-codegen scales really well. Would be awesome to automate the migration, for larger codebases. |
|
Hi, thank you for this migration file, it's super helpful! |
|
I tried migrating from Apollo Codegen to GraphQL Codegen, but it didn't work. We generate GraphQL types through Apollo Codegen using the following command and apollo client:codegen --target typescript --outputFlatmodule.exports = {
client: {
service: {
name: 'project',
localSchemaFile: 'storage/app/lighthouse-schema.graphql'
},
includes: [
'assets/shared/**/*.js',
'assets/project1/src/**/*.js',
'assets/project2/js/**/*.js',
'assets/project3/src/**/*.js'
]
}
};It's a monorepo project which uses Yarn workspaces. The GraphQL schema is generated by Lighthouse (
This is our baseline and it works well. We decided to give GraphQL Codegen a try as Therefore, I've installed GraphQL Codegen and upgraded the Then I've created the following config schema: "./storage/app/lighthouse-schema.graphql"
documents:
- assets/shared/src/**/*.js
- assets/project1/src/**/*.js
- assets/project2/src/**/*.js
- assets/project3/src/**/*.js
config: # The following configuration will adjust output to the defaults of Apollo-Codegen, and should be compatible with most use-cases.
preResolveTypes: true # Simplifies the generated types
namingConvention: keep # Keeps naming as-is
avoidOptionals: # Avoids optionals on the level of the field
field: true
nonOptionalTypename: true # Forces `__typename` on all selection sets
skipTypeNameForRoot: true # Don't generate __typename for root types
generates:
./assets/shared/__generated__/globalTypes.ts: # Equivalent for `--globalTypesFile` flag
plugins:
- typescript # Generates based types based on your schema
- typescript-compatibility
./assets/shared/__generated__:
preset: near-operation-file # Tells codegen to generate multiple files instead of one
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operations
- typescript-compatibility
Now, when I run
What would be the correct way to migrate from Apollo Codegen in to GraphQL Codegen in this particular case? Thank you! |
|
Hi @antonvialibri1, I am not certain that |
|
Hi @charlypoly, Thank you for your reply. I tried removing Here is the schema: "./storage/app/lighthouse-schema.graphql"
documents:
- assets/shared/src/**/*.js
- assets/project1/src/**/*.js
- assets/project2/src/**/*.js
- assets/project3/src/**/*.js
config: # The following configuration will adjust output to the defaults of Apollo-Codegen, and should be compatible with most use-cases.
preResolveTypes: true # Simplifies the generated types
namingConvention: keep # Keeps naming as-is
avoidOptionals: # Avoids optionals on the level of the field
field: true
nonOptionalTypename: true # Forces `__typename` on all selection sets
skipTypeNameForRoot: true # Don't generate __typename for root types
generates:
./assets/shared/__generated__/globalTypes.ts: # Equivalent for `--globalTypesFile` flag
plugins:
- typescript # Generates based types based on your schema
#- typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`
./assets/shared/__generated__:
preset: near-operation-file # Tells codegen to generate multiple files instead of one
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operations
#- typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`Should I also try removing P.S.: I left the |
|
Tried removing Then I installed Re-ran I was wondering if GraphQL Codegen is able to understand that with this setup for I have a Apollo Codegen used to undestand that and would generate types for all queries/operations within Does GraphQL Codegen treat each Thank you. |
|
Hi @antonvialibri1, sorry for the delay.
GraphQL Code Generator does take documents as a whole before processing them. I did an example project that tries to mimic your project structure and codegen configuration, and codegen is executing as expected: https://github.com/charlypoly/codegen-repros/tree/master/near-op-file-with-fragments I would need much more information to help you migrate your project (ex: look at the content of this We'll be able there to interact more easily and faster, thank you! |
|
These are the contents of the Then I have // assets/project1/src/App.js
import { UserContextFragment } from '@project/shared';
export const GET_USER_DATA = gql`
query GetUserData {
me {
...UserContextFragment
}
}
${UserContextFragment}
`;
...// assets/project3/src/App.js
import { UserContextFragment } from '@project/shared';
export const GET_USER_DATA = gql`
query GetUserData {
me {
...UserContextFragment
}
}
${UserContextFragment}
`;
...This file makes |
|
Hi @antonvialibri1, do you still get the error if you disable/comment out the |
|
Hi @charlypoly, tried removing schema: "./storage/app/lighthouse-schema.graphql"
documents:
- assets/shared/src/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.js
config: # The following configuration will adjust output to the defaults of Apollo-Codegen, and should be compatible with most use-cases.
preResolveTypes: true # Simplifies the generated types
namingConvention: keep # Keeps naming as-is
avoidOptionals: # Avoids optionals on the level of the field
field: true
nonOptionalTypename: true # Forces `__typename` on all selection sets
skipTypeNameForRoot: true # Don't generate __typename for root types
generates:
./assets/shared/__generated__/globalTypes.ts: # Equivalent for `--globalTypesFile` flag
plugins:
- typescript # Generates based types based on your schema
# - typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`
./assets/shared/__generated__:
#preset: near-operation-file # Tells codegen to generate multiple files instead of one # <------------ Commented out
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operations
# - typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`
I still get the error though: |
|
@antonvialibri1 I just spotted a possible typo. You shared your documents:
- assets/shared/src/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.jsThe path to the shared project is // assets/shared/contexts/UserContext.js
export const UserContextFragment = gql`
fragment UserContextFragment on User {
id
user {
firstname
lastname
email
}
}
`;Is documents:
- assets/shared/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.js
- assets/project1/src/**/*.js |
|
Hi @charlypoly, oh, yeah, what a shame! 😅 I set those paths wrong in the GraphQL Codegen's config file. I tried again and this config generates the types now 🎉 : schema: "./storage/app/lighthouse-schema.graphql"
documents:
- assets/shared/**/*.js
- assets/project1/src/**/*.js
- assets/project2/src/**/*.js
- assets/project3/src/**/*.js
config: # The following configuration will adjust output to the defaults of Apollo-Codegen, and should be compatible with most use-cases.
preResolveTypes: true # Simplifies the generated types
namingConvention: keep # Keeps naming as-is
avoidOptionals: # Avoids optionals on the level of the field
field: true
nonOptionalTypename: true # Forces `__typename` on all selection sets
skipTypeNameForRoot: true # Don't generate __typename for root types
generates:
./assets/shared/__generated__/globalTypes.ts: # Equivalent for `--globalTypesFile` flag
plugins:
- typescript # Generates based types based on your schema
# - typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`
./assets/shared/__generated__:
preset: near-operation-file # Tells codegen to generate multiple files instead of one
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operations
# - typescript-compatibility # <------------------------------------- Removed `typescript-compatibility`
The only thing that I noticed now is that the Shouldn't the following configuration generate all files within ./assets/shared/__generated__:
preset: near-operation-file # Tells codegen to generate multiple files instead of one
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operationsThank you! |
|
Hi @antonvialibri1, The types are generated in colocated files because you configured the Try removing the following lines: preset: near-operation-file # Tells codegen to generate multiple files instead of one
presetConfig:
extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
baseTypesPath: "./globalTypes.ts" # Points to the base types file |
Hi @charlypoly, I tried removing those lines: schema: "./storage/app/lighthouse-schema.graphql"
documents:
- assets/shared/**/*.js
- assets/project1/src/**/*.js
- assets/project2/src/**/*.js
- assets/project3/src/**/*.js
config: # The following configuration will adjust output to the defaults of Apollo-Codegen, and should be compatible with most use-cases.
preResolveTypes: true # Simplifies the generated types
namingConvention: keep # Keeps naming as-is
avoidOptionals: # Avoids optionals on the level of the field
field: true
nonOptionalTypename: true # Forces `__typename` on all selection sets
skipTypeNameForRoot: true # Don't generate __typename for root types
generates:
./assets/shared/__generated__/globalTypes.ts: # Equivalent for `--globalTypesFile` flag
plugins:
- typescript # Generates base types based on your schema
./assets/shared/__generated__:
# preset: near-operation-file # Tells codegen to generate multiple files instead of one
# presetConfig:
# extension: ".graphql.interface.ts" # Matches the existing Apollo-Codegen file-naming
# baseTypesPath: "./globalTypes.ts" # Points to the base types file
plugins:
- typescript-operations # Generates types based on your operations
However, the outcome is just an empty |
|
can you replace |
|
Hey all, what are the recommendations for configuring |
Hi @jviall, We have a dedicated documentation page on this matter: https://www.the-guild.dev/graphql/codegen/docs/integrations/apollo-local-state Let me know if you have any question, you can reach us through our Support chat available through the website. |
Is there a guide for creating presets? How would I go about doing this? |
Hello Apollo team and Apollo Codegen users!
I’m Dotan and I’ve created a library called graphql-code-generator, which we maintain for the past 4 years that aims to solve some of the same issues as Apollo Codegen.
While working with a very large codebase of one of our new clients that was using Apollo Codegen, we’ve seen that the support for Apollo Codegen and it’s issues has slowed down in recent years, (looking at the history of the apollo-codegen-core, apollo-codegen-flow and the apollo-codegen-typescript libraries, it looks like the last meaningful workload was made around August 2018) and we wanted to offer our help!
On the following issue I will try to describe everything I can about the 2 codegens, in order to collaborate together on two possible paths:
At the end, the goal here is to share all the work we’ve done in graphql-code-generator with Apollo and it’s community, in order to help Apollo in whatever way Apollo would see fit.
I will write about the difference between the codegens as they are today, two possible migration paths and a list of all open issues on Apollo Codegen that could be addressed by this collaboration.
We would love any feedback, from the great people at Apollo and it’s amazing community members!
We are currently just talking about the Typescript and Flow generators, as @designatednerd has been doing amazing work on the Swift codegen so no need for our help there!
(But we are still happy to help and collaborate there if needed, as we have Swift codegen plugins maintained by our community).
Ok here we go:
We’ve reviewed the implementation of Apollo Codegen and reviewed all open issues related to codegen on this repo and came up with a possible plan to move forward we would love your feedback on.
There are some differences in the generated output of the two generators.
We’ll explain here the differences in philosophies but we’ve also created a configuration for graphql-code-generator that generates similar output to Apollo Codegen and supports all the flag options of the Apollo CLI in order to make the switch easy and for you to have the option to gradually adopt our best practices or to simply stick with your own.
It is also a good time to kick start this collaborative initiative as we’ve started planning our next major version, GraphQL Code Generator 2.0, and would be great to get Apollo and the Apollo community be an active part in shaping that next release!
(Including the new TypedDocumentNode plugin)
First, what is GraphQL Codegen and what are the Differences compared to Apollo Codegen
Here we try to describe the current differences between the tools, even though they can be almost identical with the right configuration in GraphQL Code Generator
It’s still possible to generate multiple files (with a codegen
preset) if you wish to.TypeScript (and Flow) allow you to access nested types easily and alias it if you wish to.
possibleTypesobject required by Apollo-Client.DocumentNode- codegen can pre-compile GraphQL operations into DocumentNode and eliminate the need forgraphql-tag.Possible Migration Guide
As an Apollo Codegen user that wishes to migrate to GraphQL-Codegen, you have 2 options - either to use GraphQL Codegen and have a very similar output (with zero to minimal code changes), or adjust your project to the concepts of GraphQL Codegen. You should choose according to the size of your codebase and it’s complexity.
Option 1: Migrate to GraphQL-Codegen concepts
One of the major differences is the output itself - codegen aims to generate a single file with all the types. It’s easier for the IDE and for the TypeScript compiler.
The equivalent for TypeScript types based on GraphQL schema and operations, is the following configuration:
You can start with it, and gradually extend it with more plugins and more features, according to your needs.
Option 2: Have the same output
This solution will leverage more complex codegen features and configurations, in order to create output that will be compatible with the same file-names and identifiers names that Apollo-Codegen creates today.
The following configuration file will help you:
This should create output that is very similar and compatible with the existing Apollo-Codegen implementation, and should make it simpler for you to migrate.
Also, most of the configuration flags of Apollo-Codegen are supported in codegen, so if you are using custom setup, you should be able to use the base file above.
If your codebase is using intermediate types, you can add
typescript-compatibilityplugin to get those generated for you.List of issues / PRs and their state compared to GraphQL-Codegen
Issues
namingConvention)__typenameto identify the type correctly ;)maybeValuein configuseExactValueconfig)// @flow strictpragma #1576 - Available in codegen.codegen:generateis absurdly verbose #1297 - Codegen status update is based on listr, and not verbose when not needed.index.tsfile in codegen for typescript #1161 - Not needed in codegen.executableSchemaobject #1046 - Available in codegen.--isolatedModulesflag #2030 - Codegen doesn’t produce empty files.PRs
avoidOptionalsconfig.enumsAsTypesConfiguration mapping
The following is a reference for configuration mapping between Apollo-Codegen and GraphQL-Codegen, you might find it helpful it you are in the process of migrating it:
graph/variant/key=> You can use apollo-graph loader for that.addTypename=>addTypenamecustomScalarsPrefix/passthroughCustomScalars=>scalarsoutputFlat=> Not supported, but could be added as a preset.globalTypesFile=> simply change the output name in codegen config.excludes=> negativeglobindocumentssectionendpoint/header/localSchemaFile=>schemaitem, with url loader.includes=>documentsmergeInFieldsFromFragmentSpreads=>flattenGeneratedTypesflag.namespace=> wrapper withaddplugintagName=>pluckConfigtarget=> list of plugins - this will support only flow / typescripttsFileExtension=> will update the output extension, but also we need to make sure to change some configurations related to enums (for exampleenumAsType: true) if the extension if.d.ts.useFlowExactObjects=> flow only,useFlowExactObjectsuseFlowReadOnlyTypes=> flow only,useFlowReadOnlyTypesuseReadOnlyTypes=>immutableTypesconfiguration flagThe text was updated successfully, but these errors were encountered: