Are you open to a PR that makes Maybe and Scalars optional (use plain | null and primitive types instead)?

[ikusakov2]

Hello @dotansimha, @eddeee888,

We are currently migrating our project from Apollo Tooling to GraphQL Codegen. Our codebase is quite large, so to ensure a smooth transition, we are not yet adopting the new custom types (Maybe, InputMaybe, Scalars, Exact).

To accommodate this, we have implemented changes as a patch to the existing GraphQL Codegen plugins. However, it would be ideal if these features became part of the official plugins. For example, we envision config options such as:

config = {
    useMaybe: false,       // Default true. When false, render Maybe/InputMaybe as T | null
    useScalars: false,     // Default true. When false, use primitive types: string, boolean, number, or any
    useExact: false,       // Default true. When false, render Exact<T> as just T
    copyGlobalTypes: true  // Default false. Copy enums/types from globalTypes.ts to the output files and don't include globalTypes.ts
    // ...
}

The changes will be for typescript-operations plugin and near-operation-file preset.

Our company is willing to sponsor the work required to productize this for the open source version.
Are you open to reviewing and potentially including such a pull request?

Our aim is to make it easier and more incremental to migrate away from Apollo Tooling to GraphQL Codegen - which will hopefully benefit other people too.

Thank you,
Igor

[eddeee888]

Hi @ikusakov2 ,

Could you please share a scenario where these utilities type block the migration?

For context, there is an issue to help with migrating from Apollo tooling to Codegen, and it seems to work with majority of users: apollographql/apollo-tooling#2053

Happy to chat more to understand your use case!

[ikusakov2]

Hi @eddeee888,

Thank you for your answer!

We followed the migration guidance from apollographql/apollo-tooling#2053 , but the generated output differs from our previous Apollo Tooling setup. Our codebase is large, so we’re trying to keep code changes to a minimum (at least for the first phase of the migration).

Here is the list of differences that we observed:

1. The generated type files in __generated__ directories were named based on containing typescript files (such as react components). However, in the original Apollo tooling they were named based on operations (query, mutation or fragment).

2. GraphQL Cogegen introduces custom types (Scalars, Maybe, InputMaybe, Exact). While we understand the reasons for these types, adding them would require noticeable change to our codebase (in cases when these types are cloned in the actual code - for example in react component props), which we try to avoid.

In the existing issue: #2048, it looks like there was a discussion to add a feature to avoid these custom types.

3. Generated types refer to global enums/types from the schema. In GraphQL Codegen this appears to be hardcoded to an import from the src/__generated__/globalTypes.ts. Our original Apollo tooling implementation included the required global types inside the generated files. This is a preferable approach for us.

4. Imagine a monorepo, where a package A refers to a graphql fragment in package B. In such case, we would need to include the src paths to both A and B as documents to GraphQL Codegen config. And, GraphQL Codegen will always generate files for both packages: A and B, even if we only need them for A (at least I have not found a way to skip generating B through configuration). Because we have a lot of such cross-includes in our monorepo, and our generation script runs multiple parallel processes, there is a potential race condition, when multiple processes are trying to generate same files for an included repo.

We have resolved these issues for our case through plugin patches.
However, our changes are specific to our needs. We would like, if possible, to make them generic.

Thank you,
Igor