preResolveTypes doesn't respect naming convention/prefix config options

[joshlam]

Describe the bug

Let's say you have your config set to convert type names to pascalCase and prefix types with I. You also have a type in your GraphQL schema named My_Type_Yo.

When preResolveTypes is false and this type is part of a Pick, this will output something like

...
Pick < IMyTypeYo, 'id' >
...

However, when preResolveTypes is true, formatting related config is ignored:

...
        id: My_Type_Yo,
...

Expected behavior

I would expect the config relating to conversions (pascal case, prefixing, etc.) to be respected so that the output uses types that exist within the codegen, not the non-converted type names straight from my schema.

Additional context

Skimming through the preResolveTypes change (#2107), it looks like the convert name function isn't being applied within the new {...}withoutPick methods.

[dotansimha]

Hi @joshlam
I'm not sure how to reproduce it. I tested it but the result it: id: string and not My_Type_Yo. Maybe I'm missing something, can you please provide a reproduction for this?

[joshlam]

@dotansimha

Sorry, gave an incorrect example. The id will be coming from an enum.

Here is an example .graphql file:

type Information {
    entries: [Information_Entry!]!
}

enum Information_EntryType {
  NAME
  ADDRESS
  ...
}

type Information_Entry {
  id: Information_EntryType!
  value: string
}

Fragment:

fragment information on Information {
  entries {
    id
    value
  }
}

Generated types with preResolveTypes false:

export type IInformationFragment = {
  entries: Array < ({
        __typename ? : 'Information_Entry'
    } & Pick < IInformationEntry, 'id' > & 
    ...
)

Generated types with preResolveTypes true:

export type IInformationFragment = {
    entries: Array < {
        __typename ? : 'Information_Entry',
        id: Information_EntryType,
        ...
    } > 
};

[dotansimha]

Thanks, I'm taking a look :)

[dotansimha]

Fixed in: #2284 , available as alpha: 1.4.1-alpha-906f6449.78.

[joshlam]

@dotansimha Thanks for the fix! I'm running into an issue now though where types are no longer generated for some fragments, will investigate

[dotansimha]

@joshlam can you please share a reproduction?

[joshlam]

@dotansimha

It looks like what's happening is that files that import other fragments aren't getting types generated.

Config:

overwrite: true
schema: path/to/schema
documents: src/**/*.gql
generates:
    codegen/graphql.d.ts:
        plugins:
            - 'typescript'
            - 'typescript-operations'
        config:
            namingConvention:
                enumValues: keep
                typeNames: change-case#pascalCase
            preResolveTypes: true
            typesPrefix: I
    codegen/graphql.schema.json:
        plugins:
            - 'fragment-matcher'

If I have two files

src/fragments/clickEventInfo.gql:

fragment clickEventInfo on ClickEvent {
  __typename
  .
  .
  .
}

and
src/fragments/blah.gql:

#import 'src/fragments/clickEventInfo.gql'

fragment blah on Blah {
  clickEvent {
    ...clickEventInfo
  }
}

A type will only be generated for the IClickEventInfoFragment.

[dotansimha]

Thanks @joshlam . I'm not sure it's related to those changes, maybe it's another change we did. Any chance you can open a new issue for that?

[joshlam]

Yeah, it's a separate issue since encountering it with and without the preResolveTypes. Will open a new issue

[jkillian]

I noticed when upgrading from 1.4.0 to "@graphql-codegen/typescript-operations@1.4.1-alpha-680e7b39.95" . that I see diffs like this:

This is with preResolveTypes: true and enumAsTypes not set. Is this an intended diff? Just wanted to mentioned it before the next release 😄

[dotansimha]

@jkillian it's fine, because now enums are also resolved into a primitive value :)

[dotansimha]

Fixed in 1.5.0 🎉

[jkillian]

@dotansimha I'm afraid there's still issues here I believe. For example, I have this fragment type:

this enum gets generated:

and this actual type gets generated:

Notice how CredentialDocument.status is the enum type DocumentStatus, but DocumentsTableFragment.statusis a string literal type. Unfortunately, this means thatDocumentsTableFragment.statusis not assignable toCredentialDocument.status` because of the way TypeScript handles string enums. This inconsistency in the generated types can lead to some tricky difficulties in user code.

Does this make sense? Let me know if you need more info or if I'm misunderstanding something!

Edit: This is my config in case it helps!

    config:
      avoidOptionals: true
      dedupeOperationSuffix: true
      namingConvention:
        enumValues: change-case#constantCase
      operationResultSuffix: "Result"
      maybeValue: "T | undefined | null"
      preResolveTypes: true
    plugins:
      - "typescript"
      - "typescript-operations"
      - "typescript-resolvers"