Bug: enumValues with external imports creates invalid re-export syntax and name mismatches between plugins

[ItaiYosephi]

Which packages are impacted by your issue?

@graphql-codegen/cli, @graphql-codegen/typescript-operations, @graphql-codegen/typescript

Describe the bug

Description

When using the enumValues configuration to import an external enum with a different name than what appears in the GraphQL schema, the generated code has two issues:

1. Invalid re-export syntax: The codegen generates invalid TypeScript/JavaScript when it tries to re-export an import alias
2. Name mismatch: The typescript and typescript-operations plugins use different names for the same enum

Current Behavior

Given this configuration:

config: {
  enumValues: {
    LicenseSKU: '../shared-generated-enums#LicenseSku',
  }
}

Where the GraphQL schema has:

enum LicenseSKU {
  BASIC
  ADVANCED
  # ...
}

The codegen generates:

// At the top of the file
import { LicenseSku as LicenseSKU } from '@wiz-sec/tenant-shared/graphqlTypes';

// In type definitions from typescript-operations plugin
export type SomeQuery = {
  license: {
    sku: LicenseSku; // ❌ This type doesn't exist - it expects the imported name
  }
}

// At the bottom of the file  
export { LicenseSKU }; // 

Expected Behavior

When using enumValues with an external import, the codegen should use the schema name consistently: Both typescript and typescript-operations plugins should reference the enum by the same name

Suggested Solution

The enum should be aliased internally to match what would be generated if enumValues were not provided.
in our example, the import should have been:

import { LicenseSku as LicenseSku } from './shared';
// or just
import { LicenseSku  } from './shared';

Workaround

Currently we have to add a manual alias using the add plugin:

{
add: {
   content: `export const TenantLicenseSku = TenantLicenseSKU; export type TenantLicenseSku = TenantLicenseSKU;`,
},
}

Environment

• @graphql-codegen/cli: ^5.0.7
• @graphql-codegen/typescript: ^4.1.6
• @graphql-codegen/typescript-operations: (latest)
• Node version: 22.x
• OS: macOS

Your Example Website or App

https://codesandbox.io/p/sandbox/github/dotansimha/graphql-code-generator-issue-sandbox-template

Steps to Reproduce the Bug or Issue

just open types.ts, and see that import:

import { LicenseSku as LicenseSKU } from './shared';

and LicenseQuery expects LicenseSku

export type LicenseQuery = {
  __typename?: 'Query';
  license: { __typename?: 'License'; sku: LicenseSku // wrong! };
};

Expected behavior

When using enumValues with an external import, the codegen should use the schema name consistently: Both typescript and typescript-operations plugins should reference the enum by the same name

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• NodeJS: [e.g. 18.5.0]
• graphql version: [e.g. 16.3.0]
• @graphql-codegen/* version(s): [e.g. 2.6.2]

Codegen Config File

No response

Additional context

No response

[eddeee888]

Hello!
We are looking to improve client types in the upcoming major version: #10479
This looks like it'd be solved by that. Let me know what you think!

[ItaiYosephi]

Hi @eddeee888!
Thank you for directing me to the improvements planned for the next major version. I appreciate the ongoing efforts to enhance client types.
In our monorepo setup, we have two distinct schemas and several shared enums (and types...) that are used across both schemas. Our aim is to generate these shared enums in a dedicated package within the monorepo, ensuring that any application using either schema 1 or schema 2 can utilize these enums consistently.
Currently, ⁠importSchemaTypesFrom: './types.generated.ts' doesn't fully support sharing enums across schemas. While ⁠enumValues can map GraphQL enums to TypeScript enums, it requires manual configuration, which is not ideal. If ⁠enumValues remains compatible with ⁠importSchemaTypesFrom: true, that would suffice, but addressing the bug I reported is still crucial. Ideally, having a seamless way to ensure all shared enums are used from the shared package would be even better.
I hope this clarifies our challenges. Any insights on how the upcoming changes might address these would be greatly appreciated!
Thank you!

[eddeee888]

In our monorepo setup, we have two distinct schemas and several shared enums (and types...) that are used across both schemas. Our aim is to generate these shared enums in a dedicated package within the monorepo, ensuring that any application using either schema 1 or schema 2 can utilize these enums consistently.

This is interesting! I usually don't recommend sharing enum from two different schema as they may evolve independently.
Would generating types into 2 shared packages, one for each schema work for you?

Note that when we move to the new major version, the "shared" generated types of a schema will be influenced by the document of each schema i.e. we cannot really share types between schema. Another way to think about it is just because the values look the same between schemas, it doesn't mean they should be shared,