Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Disabled mapper resolver generation #317

Closed
marisbest2 opened this issue Jul 11, 2024 · 4 comments
Closed

[BUG] Disabled mapper resolver generation #317

marisbest2 opened this issue Jul 11, 2024 · 4 comments

Comments

@marisbest2
Copy link

(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

  • OS: MacOS
  • Package name and version: "@eddeee888/gcg-typescript-resolver-files": "^0.10.2" (but appears to be long standing behavior)

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

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 eddeee888 mentioned this issue Jul 14, 2024
10 tasks
@eddeee888
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants