[typed-document-node] generated Fragment types are incorrectly prefixed with Types. namespace on 6.1.0+

[pachuka]

Which packages are impacted by your issue?

@graphql-codegen/typed-document-node

Describe the bug

When using typed-document-node@6.1.0+ with the import-types preset, the generated code incorrectly adds a Types. prefix to all DocumentNode result types, including fragments. This causes TypeScript compilation errors because:

1. Operation types come from the external Types namespace (correct)
2. Fragment types are generated locally and should NOT be prefixed (but they are)

Root Cause

In PR #10456 (commit 655b91d), the typed-document-node plugin added the importOperationTypesFrom feature. The implementation indiscriminately applies the Types. prefix to ALL non-unknown result types without distinguishing between:

• Operations (should be prefixed - they come from external Types namespace)
• Fragments (should NOT be prefixed - they're generated locally)

Source: visitor.ts lines 101-103:

const resultImportPrefix = shouldUseImportPrefix && resultType !== 'unknown' ? 'Types.' : '';

Your Example Website or App

https://github.com/pachuka/-graphql-codegen-typed-document-node-fragment-namespace-bug

Steps to Reproduce the Bug or Issue

1. Pull down the reproduction repo
2. npm install
3. npm run codegen
4. npm run build // should fail
5. update package.json to downgrade @graphql-codegen/typed-document-node to 6.0.2
6. repeat steps 2-4 (build should pass)

Expected behavior

Fragments should not be prefixed with the Types namespace when used w/import-types preset.

Screenshots or Videos

No response

Platform

• OS: macOS
• NodeJS: 24.7.0
• graphql version: 16.12.0
• @graphql-codegen/typed-document-node version(s): 6.1.0+

Codegen Config File

overwrite: true
schema: schema.graphql
documents: operations.graphql
generates:
  generated.ts:
    preset: import-types
    presetConfig:
      typesPath: ./types
    plugins:
      - typescript
      - typescript-operations
      - typed-document-node
    config:
      scalars:
        DateTime: Date
      namingConvention:
        typeNames: change-case#pascalCase
        enumValues: change-case#upperCase
  types.ts:
    plugins:
      - typescript
    config:
      scalars:
        DateTime: Date

Additional context

No response

[eddeee888]

Hi @pachuka , I've had a look at your example, and there are a few things that stood out re. config:

overwrite: true
schema: schema.graphql
documents: operations.graphql
generates:
  generated.ts:
    preset: import-types
    presetConfig:
      typesPath: ./types
    plugins:
      - typescript
      - typescript-operations
      - typed-document-node
    config:
      scalars:
        DateTime: Date
      namingConvention:
        typeNames: change-case#pascalCase
        enumValues: change-case#upperCase
  types.ts:
    plugins:
      - typescript
    config:
      scalars:
        DateTime: Date

1. typescript is being used in multiple generates block. This seems odd. Could you help me understand why you'd need it?
2. If you are already generating types into generated.ts, is there a reason to import the same types from another file?
3. Should import-types be updated to say where imports the types from?

I feel this is a misconfiguration issue. Could you help me understand if this setup is a recommendation from our guides? (I'm keen to fix it if so)

I believe the following config should work:

overwrite: true
schema: schema.graphql
documents: operations.graphql
generates:
  generated.ts:
    preset: import-types
    presetConfig:
      typesPath: ./types
    plugins:
      - typed-document-node
  types.ts:
    plugins:
      - typescript
      - typescript-operations
    config:
      namingConvention:
        typeNames: change-case#pascalCase
        enumValues: change-case#upperCase
      scalars:
        DateTime: Date

[pachuka]

Hey @eddeee888 thanks for the quick reply! Ah I should have added a little more detail the reproduction isn't exactly our real configuration was trying to make a more isolated demonstration; but I do see your suggestion fixes it for the reproduction.

In our real case we publish a graphql-codegenerated types package from our api-server which has a generation schema like so:

api-gateway:

overwrite: true
schema: schema_full.generated.graphql
generates:
  src/api-gateway.ts:
    plugins:
      - typescript

config:
  scalars:
    DateTime: Date
  immutableTypes: true
  namingConvention:
    typeNames: change-case#pascalCase
    enumValues: change-case#upperCase
    transformUnderscore: true
  avoidOptionals: false

the output of that gets packaged up as a NPM package which is pulled in/consumed in our client types generation

client:

overwrite: true
schema: ../../node_modules/@namespace/api-gateway-types/schema_full.generated.graphql
generates:
  src/client.ts:
    documents: src/**/**.graphql
    preset: import-types
    presetConfig:
      typesPath: '@namespace/api-gateway-types'
    plugins:
      - add:
          content: '/* THIS FILE WAS GENERATED BY GRAPHQL CODE GENERATOR. DO NOT EDIT. */'
      - add:
          content: '/* eslint-disable */'
      - typescript-operations
      - typed-document-node

  src/sdk.ts:
    documents: src/**/**.graphql
    plugins:
      - add:
          content: '/* THIS FILE WAS GENERATED BY GRAPHQL CODE GENERATOR. DO NOT EDIT. */'
      - add:
          content: '/* eslint-disable */'
      - typescript-graphql-request
    config:
      typesPrefix: Operations.
      documentMode: external
      importDocumentNodeExternallyFrom: ./client

  src/fragment-matcher.ts:
    plugins:
      - fragment-matcher
    config:
      useExplicitTyping: true

config:
  scalars:
    DateTime: Date
  immutableTypes: true
  namingConvention:
    typeNames: change-case#pascalCase
    enumValues: change-case#upperCase
    transformUnderscore: true
  avoidOptionals: false
  dedupeFragments: true
  preResolveTypes: false
  inlineFragmentTypes: combine

hooks:
  afterAllFileWrite:
    - prettier --write

To be honest I set this up years ago at this point; so you are probably right that I've got some configuration issues with this.

Sounds like I should be separating the typed-document-node usage from the typescript-operations though?

[eddeee888]

To be honest I set this up years ago at this point; so you are probably right that I've got some configuration issues with this.

No worries! Thanks for sharing the reproduction repo so I could play around with 🙂

Sounds like I should be separating the typed-document-node usage from the typescript-operations though?

Yes, I think that'd be the easiest approach. That way we are saying "import all types from xxxx.ts file".
Also, we are doing an overhaul on typescript-operations, so very soon you won't be needing the typescript plugin for client use cases: #10479

[pachuka]

Okay I think I'm making progress; here's what my config is looking like now (left out the annotations for readability):

  src/operations.ts:
    documents: src/**/**.graphql
    preset: import-types
    presetConfig:
      typesPath: '@namespace/api-gateway-types'
    plugins:
      - typescript-operations

  src/client.ts:
    documents: src/**/**.graphql
    plugins:
      - typed-document-node
    config:
      importOperationTypesFrom: './operations'

  src/sdk.ts:
    documents: src/**/**.graphql
    plugins:
      - typescript-graphql-request
    config:
      typesPrefix: Operations.
      documentMode: external
      importDocumentNodeExternallyFrom: ./client

  src/fragment-matcher.ts:
    plugins:
      - fragment-matcher
    config:
      useExplicitTyping: true

operations.ts looks good
client.ts looks right except looks like it doesn't actually add the import at the top of the file 🤔

missing import * as Types from './operations'; is this a config issue, or am I misunderstanding/missing something?

If I manually add that via add to the src/client.ts section

      - add:
          content: 'import * as Types from "./operations";'
          prepend: true

then it all introspects/builds properly.

Note the lack of Types import in the generated client.ts:

I can take some time tomorrow to make a better reproduction that has the full structure with the separate package just to make it easier as well.

[pachuka]

Ah nevermind; I see what I did wrong; the following seems to work for me :). Will do some final validation and then we can close this out.

  src/client.ts:
    documents: src/**/**.graphql
    preset: import-types
    presetConfig:
      typesPath: ./operations
    plugins:
      - typed-document-node