Support Generating a Record Type

[aidant]

Description

When defining a GraphQL type of name Record the generated types reference the generated Record type rather than the Record type from TypeScript when trying to define a generic for ResolversUnionTypes and ResolversInterfaceTypes.

Type of change

• [x] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

The following patch has been applied in the repo with the effected types:

diff --git a/node_modules/@graphql-codegen/visitor-plugin-common/cjs/base-resolvers-visitor.js b/node_modules/@graphql-codegen/visitor-plugin-common/cjs/base-resolvers-visitor.js
index 4d4adf3..cdefaba 100644
--- a/node_modules/@graphql-codegen/visitor-plugin-common/cjs/base-resolvers-visitor.js
+++ b/node_modules/@graphql-codegen/visitor-plugin-common/cjs/base-resolvers-visitor.js
@@ -415,7 +415,7 @@ class BaseResolversVisitor extends base_visitor_js_1.BaseVisitor {
         return new utils_js_1.DeclarationBlock(this._declarationBlockConfig)
             .export()
             .asKind(declarationKind)
-            .withName(this.convertName('ResolversInterfaceTypes'), `<RefType extends Record<string, unknown>>`)
+            .withName(this.convertName('ResolversInterfaceTypes'), `<RefType extends { [key: string]: unknown }>`)
             .withComment('Mapping of interface types')
             .withBlock(Object.entries(this._resolversInterfaceTypes)
             .map(([typeName, value]) => (0, utils_js_1.indent)(`${typeName}: ${value}${this.getPunctuation(declarationKind)}`))

Checklist:

• [ ] I have followed the CONTRIBUTING doc and the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 4d461c8c5da20651f56646fe82d8473d8e202d87

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[eddeee888]

Hi @aidant , can you help me understand why the issue you are facing with Record<string, unknown> please? 🙂 Or maybe some resources explaining the difference between Record<string, unknown> and { [key: string]: unknown }

[gilgardosh]

If I understand correct, the aforementioned issue is dealing with a case when schema contains GraphQL type named Record, which then overrides TS's Record resulting in some issues, did I get that right @aidant ?

If so, we should add a mechanism to prevent this (and any other usage of preserved TS utility types names). In any case, the approach IMO shouldn't be avoiding utility types as in the suggested fix, but renaming the schema types with some consistent convention.

[aidant]

@gilgardosh correct. I would be happy to avoid this issue with a prefix of all types by using the typesPrefix option. Which I did try at some point as we would like to have all of our generated types prefixed with Api but there are unrelated issues with the generated types when a prefix is used. I don't remember the exact details off the top of my head, but can open a separate issue once I have time.

I understand your hesitations for avoiding utility types and am happy for a different fix to be implemented in the long term. But for an immediate fix this elevates the issue as Record<string, unknown>> and { [key: string]: unknown } are equivalent types.

Something else to consider is this generic is not used in certain cases (including mine), which seems to be causing issues for people with what I suspect is noUnusedLocals and/or noUnusedParameter enabled, see #9584