eddeee888 / graphql-code-generator-plugins

List of GraphQL Code Generator plugins that complements the official plugins.
MIT License
50 stars 12 forks source link

[BUG] Disabled mapper resolver generation #317

Closed marisbest2 closed 1 month ago

marisbest2 commented 1 month ago

(Note, this may be intended behavior in which case consider this a FR)

Describe the bug When I have mappers and resolverGeneration: disabled I expect there to not be resolvers generated but there are. The docs say

disabled: generates no resolvers. Use this if you want to use your own structures. Note: if custom scalars are detected and used, resolver main files are still generated.

To Reproduce

  1. Have mappers
  2. Set resolverGeneration: disabled
  3. Run generate command
  4. Observe that resolvers were generated for your mapped types

Expected behavior I expect resolvers to not be generated

Versions

Additional context Full config:

schema: '**/schema.graphql'
generates:
  '.':
    preset: '@eddeee888/gcg-typescript-resolver-files'
    presetConfig:
      mode: modules
      typeDefsFileMode: modules
      resolverGeneration: disabled
      typesPluginsConfig:
        federation: true
        useIndexSignature: true
        resolversNonOptionalTypename: true
      scalarsOverrides:
        ID:
          type: string

hooks: { afterAllFileWrite: ['prettier --write'] }

Why I want this: I have existing resolvers which all work nicely. Now I'm layering in the types and I don't want to move them all. Mappers should make my life a lot easier. But I definitely don't want to move all my resolvers around.

eddeee888 commented 1 month ago

Hi @marisbest2,

I see your point 👍 The naming is a bit confusing at the moment and I'll look to improve this soon.

resolverGeneration has evolved a bit. Like you expected, disabled should avoid generating resolver files (and it did in the past). However, it is currently behaving as "do not generate resolver files by default, but run static analysis to catch runtime error, especially if there's mappers".

To take full control i.e. disabling type wireup and static analysis, you can use externalResolvers to point to your own resolver implementation:

defineConfig({
  resolverGeneration: 'disabled',
  externalResolvers: {
    TypeA: './path/to/TypeAFile#TypeA',
    TypeB: './path/to/TypeBFile#TypeB',
    // other files you want to take full control of...
  },
}),

Note that you'd have to add all the files you don't want the server preset to run analysis here, for now. I'll look into improving these config in the near future so that they have better names, and better documented

marisbest2 commented 1 month ago

Cool I'll give that a try.

I think I'd suggest "disabled" to mean "don't generate any resolvers" and then something else to mean "do the bare minimum". I guess that'd be a breaking change, so maybe keep "disabled" to mean what it means and add a "off" option which just completely skips that step?

Alternatively maybe a "types-only" mode?

Anyway thanks!

eddeee888 commented 1 month ago

Yes, that's a great suggestion 👍 I'm working towards v1 and there's going to be breaking changes for of config naming and behaviour. This feedback will help with that 🙌

eddeee888 commented 1 month ago

Closing this as discussion has finished and we have a workaround.