You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the Bug
When extending an @ArgsType() using mixins, if you override a field in an attempt to change the @Field type (for example, in order to use a custom scalar, or to change nullability), the schema does not correctly represent the overridden type, but rather the base type.
However, if you extend a base @ArgsType() class and define the override inline, the overridden type is correctly reflected in the schema.
Looks like this is not related to mixins but deeply nested inheritance at all.
It's because of using while loop for super class traversal in order, instead of doing it from top to bottom.
The fix should be fairly easy to implement, working on it rn 😉
wow! that was a much faster fix than I expected, thanks!
any idea when you might be doing the next release @MichalLytek ? i'm working on overriding several hundred generated types from typegraphql-prisma and this would sure make the work a lot easier/cleaner ;)
Describe the Bug
When extending an
@ArgsType()
using mixins, if you override a field in an attempt to change the@Field
type (for example, in order to use a custom scalar, or to change nullability), the schema does not correctly represent the overridden type, but rather the base type.However, if you extend a base
@ArgsType()
class and define the override inline, the overridden type is correctly reflected in the schema.To Reproduce
schema output:
Expected Behavior
The schema output shows that
take
is required.Environment (please complete the following information):
Additional Context
changing the override to NOT use mixins causes the schema to correctly reflect the non-nullability:
schema output:
The text was updated successfully, but these errors were encountered: