[client-preset] allowed options and defaults

This issue is the place to discuss allowed options and default values when using the preset: 'client' setup.

Currently supported options

• scalars
• strictScalars
• namingConvention
• useTypeImports
• skipTypename
• enumsAsTypes
• arrayInputCoercion
• presetConfig.fragmentMasking
• presetConfig.gqlTagName
• presetConfig.unmaskFunctionName
• emitLegacyCommonJSImports

Requested options support

• nonOptionalTypename (https://github.com/dotansimha/graphql-code-generator/issues/8296#issuecomment-1287010974)
• immutableTypes (https://github.com/dotansimha/graphql-code-generator/issues/8296#issuecomment-1287010974)

Current defaults

• presetConfig.fragmentMasking: true
• inlineFragmentTypes: true (if fragment masking is enabled)
• emitLegacyCommonJSImports: true

Requested defaults

• ignoreNoDocuments: true (@charlypoly)
• should presetConfig.fragmentMasking be false by default? (@charlypoly)
• dedupeFragments: true (https://github.com/dotansimha/graphql-code-generator/issues/8103#issuecomment-1298692748)
• enumsAsTypes: true (@n1ru4l)

[n1ru4l]

@ShravanSunder I agree with all your proposals - except maybeValue: 'T | undefined | null',. The maybe/value for nullable fields should be T | null - it can never be undefined.

[n1ru4l]

nonOptionalTypename is dangerous IMHO - It allows the wrong configuration.

E.g. the correct type for

query MeQuery {
  me {
    id
  }
}

is

type MeQuery = {
  me: {
    id: string
  }
}

not

type MeQuery = {
  me: {
    __typename?: "User",
    id: string
  }
}

or

type MeQuery = {
  me: {
    __typename: "User",
    id: string
  }
}

However, GraphQL clients such as apollo and urql ADD __typename selections to the documents before sending them to the GraphQL server. I am unsure whether I like this behavior. But if you look at this it makes sense why the defaults are like they are today.

Having that said, for me, the following makes the most sense:

• __typename is OMITTED from the generated types by default.

---

Adding the __typename property to the generated type via a configuration option by default, either as optional or mandatory - is something I would ideally try to avoid - but I can also see why people don’t want to explicitly clutter their GraphQL Operation documents with __typename selections.

In order to make the apollo/urql users happy this means we will kind of need an automaticallyAddTypenameSelection configuration.

This is a potential proposal that groups the configuration under one object property:

type AutoTypenamesSelectionConfig = boolean | {
  skipRootTypes?: boolean
}

I don’t event think we need to allow adding __typename properties as optional - it should either be non-optional or not at all present.

Curious to hear the use-cases of having __typename?: "User".