Split Swagger and ZodToDto into two separate packages?

[RIP21]

Hey, my team is currently using class-validator which I'm not a fan of it at all :) With Nest.js which means we're pretty locked on classes being available in the runtime for Nest to be happy. I try to find a way to migrate towards zod for validation as much as I can, but the Swagger part is pretty useless for us as we're using GraphQL, so having Swagger imported even if we're not using it, is a bit wasteful. To guarantee that Swagger stuff will never get into the runtime/compile-time no matter the setup, having it as a separate module will be nice. Since you have rush.js setup, I guess, it should be pretty straightforward to achieve :)

Afterthoughts, I guess, with GraphQL we will have to stick to class-validator as, well, all GraphQL stuff is done using decorators, so we won't be going away from classes for DTOs/InputTypes/Models, but, anyway, having it separated is just a good thing anyway.

[kbkk]

Hi,

Thanks for the input!

my team is currently using class-validator which I'm not a fan of it at all

High five, < insert my rant on class-validator/class-transformer here > :)

having Swagger imported even if we're not using it, is a bit wasteful

The swagger bit is optional and @nestjs/swagger is a peer-dependency zod-dto, hence it's not installed until you explicitly make it so. It should not be an issue at all.

Since you have rush.js setup, I guess, it should be pretty straightforward to achieve :)

Yes, it should be. If given the above you'd still like these libs separated feel free to make a PR. The release process is not automated yet so I'll release it manually.

Afterthoughts, I guess, with GraphQL we will have to stick to class-validator

Sadly I cannot advise you here as my GraphQL knowledge is extremely basic but I believe it'd be possible to integrate zod and GraphQL. I am not sure if I'd use that in an enterprise setting though.

[RIP21]

Sadly not a user of the lib to contribute now, maybe someday as I'm full of Nest....

Dayum I hate class-transformer and class-validator. Not a big fan of Nest JS TBH. I had enough of Spring "magic" in Java to bring that stuff into JS :D (also as decorators and especially decorator metadata is nowhere near to be a part of JS) It also plays pretty badly with TS. But, whatever, I won't be able to change that, but I would prefer only some container to get instances and shit from it, but rest just function and composition and duck typing. new classes, getters and other stuff is killing me as TS is a pile of garbage to work with when you do OOP Java style with it. Like... if you like all that shit, go write Kotlin ffs :D (lovely language tho)