Open dylanwulf opened 2 months ago
Hi @dylanwulf ,
I found that the problem seems to stem from the custom DeepPartial
. When I remove it from the codegen config, it works fine.
Could you please let me know your use case with DeepPartial
? This seems to be fairly commonly used in some setup but I haven't found a use case for it.
Hi @dylanwulf ,
I found that the problem seems to stem from the custom
DeepPartial
. When I remove it from the codegen config, it works fine.Could you please let me know your use case with
DeepPartial
? This seems to be fairly commonly used in some setup but I haven't found a use case for it.
@eddeee888 We use @graphql-tools/mock
when providing mock graphql data to our frontend unit tests. @graphql-tools/mock
allows us to specify deeply partial data, and it will automatically generate any missing data in a way that conforms to our graphql schema. DeepPartial
allows us to have type safety when providing this deeply partial data.
I see @dylanwulf . Could you please show some code snippet how you'd set up @graphql-tools/mock
? I'm looking at the doc but can't imagine how codegen type's used with it (This is the first time I'm looking into it)
Regarding, the Maximum call stack size exceeded
issue, I'm trying to think what's the best way to handle it. But I'm guessing DeepPartial
loops through nested types which causes the infinite loop issue at typecheck.
Something is reallly different about typescript-resolvers 4.2.1, the types that were generated for my project were so inefficient that I couldn't even get typescript to build my project, I generated a trace and it ended up being 34GB, the build info wouldn't even write to a file because the size was > JSON.stringify allowed. vscode was also complaining about infinite types and my editor was totally janked as well. Downgraded to 4.1.0 and the problems disappeared. Not saying that I didn't somehow write my types in a way that was causing everything to blow up but I wasted two days trying to fix this and realized 4.2 was the issue. I was also using a defaultMapper
and this may have something to do with that feature and the codegen output differences seemed to mostly be related to union types.
Hi @kyle-villeneuve , could you please let me know the value of defaultMapper
?
// codegen.config.ts
defaultMapper: 'DeepPartialGQL<{T}>'
// type definition
export declare const __brand: unique symbol;
export type OpaqueType<T, K extends string = 'BRANDED_TYPE'> = T & { readonly [__brand]?: K };
type ValueOf<T> = T[keyof T];
export interface DeepPartialArray<T> extends Array<DeepPartialGQL<T>> {}
export declare type DeepPartialObject<T> = {
[P in keyof T]?: DeepPartialGQL<T[P]>;
} & { __typename?: string };
export declare type DeepPartialGQL<T> = T extends Function
? T
: T extends Array<infer U>
? DeepPartialArray<U>
: T extends ValueOf<Opaque>
? T | undefined | null
: T extends object
? DeepPartialObject<T>
: T | undefined | null;
May I know the reason you are using DeepPartialGQL
in your config @kyle-villeneuve ? 🙂
@eddeee888 Yeah, this is for server side code, and my resolvers don't always return the full type, sometimes there is additional fetching in the "leaves" subtypes so I allow returning partial responses while still ensuring type safety to some degree
Thanks @kyle-villeneuve , have you tried using mappers? This option is designed to allow you to return a consistent value in resolvers, so the next resolvers in the chain can use said returned type. It's the better way to enforce type-safety and consistency IMO 🙂
@eddeee888 I did yeah but that ended up being too restrictive for my use case
I'll see what I can do 🙂
Just a note, mappers
will have first-class support so new features will be tested against it. I think defaultMapper
was added to support some use cases but may not have the guarantee to always work.
I'll see what I can do 🙂 Just a note,
mappers
will have first-class support so new features will be tested against it. I thinkdefaultMapper
was added to support some use cases but may not have the guarantee to always work.
This is a bit confusing because both features are documented with the same level of importance and there's no indication provided other than this comment that users should avoid defaultMapper
. In fact, this exact use of DeepPartial
as the defaultMapper
is an example from the docs.
You are right, let me have a chat with the team to understand this a bit more.
Hi all,
There will be an option called avoidCheckingAbstractTypesRecursively
. Please use it together with the defaultMapper
option if defaultMapper
is recursive:
config: {
defaultMapper: 'DeepPartial<{T}>',
avoidCheckingAbstractTypesRecursively: true // required if you have complex nested abstract types
},
There's an alpha version here: 4.4.0-alpha-20241014102200-ddc58bcd59abae2c907ea72c013c42ae94232b54
Please try it out and let me know if it fixes the issue. Once confirmed, I can try to release it ASAP.
@eddeee888 Thank you! That alpha version with the new option fixes the issue for me!
Which packages are impacted by your issue?
@graphql-codegen/typescript-resolvers
Describe the bug
With the v4.2.1 release of
@graphql-codegen/typescript-resolvers
, I started seeing an errorMaximum call stack size exceeded
when running the typescript compiler. This did not happen on v4.2.0.Your Example Website or App
https://github.com/dylanwulf/graphql-code-generator-issue-sandbox-template/tree/typescript-resolvers-max-call-stack-exceeded
Steps to Reproduce the Bug or Issue
typescript-resolvers-max-call-stack-exceeded
npm install
npm run codegen
(optional -- the types have already been generated and committed)npm run typecheck
Expected behavior
I expected no error
Screenshots or Videos
No response
Platform
graphql
version: seepackage.json
in linked github repo@graphql-codegen/*
version(s): seepackage.json
in linked github repoCodegen Config File
See linked github repo
Additional context
The full error output I see in the console: