how might @zodios/nestjs look like?

[firxworx]

Hey I stumbled across zodios and think its awesome what you are doing. I saw the roadmap has @zodios/nestjs and I think that would be the cherry on top for a powerhouse TS stack.

I'm curious how you envision integration with NestJS? What might the integration with NestJS and dev experience look like in your ideal scenario? I'm guessing from the zodiosApp API you might have an idea to do something different than a typical idiomatic NestJS app?

I figure there are plenty of options to elegantly work in zodios-style thinking with NestJS especially if using it with Express vs. Fastify where it would be compatible with express middleware and you can access the Express req + res.

I guess possible integration approaches include implementing a ZodiosModule that gets passed the API configuration as config, or perhaps a ZodiosController + ZodiosService combo that could be added (perhaps extended by controller + service classes) to bring them into an existing NestJS module.

Nest also has the ability to use global interceptors, filters, etc that could serve as integration points.

I assume you've seen https://github.com/anatine/zod-plugins
Those are more tools for an idiomatic NestJS approach such as a validation pipe that works with zod schemas.

[ecyrbe]

Hello @firxworx ,

Thank you for the kind words. I'm sad to tell you that for the moment, i've not yet followed the rabbit hole of integrating NestJs.
My current v11 plan do not yet have NestJs in the works.

One issue that i see for the moment is that typescript decorators do not work well with typesafety since they don't add any type to typescript signature.
So any integration would be either :

• to still use decorators, but loose some type safety (like ts-rest did), but i don't like the idea to loose typesafety
• not use decorators, but a use a more functional approach, but this defeats using nest js
• use a giant decorator on controller to plug the service to the controller

The last one is i think the only one that could preserve full typesafety.
I have yet to design something satisfactory.
But the idea of a giant decorator is not unknown in NestJs, so maybe this could be the way.

[firxworx]

Thanks for the update on your roadmap I really appreciate it. Your thoughts are very insightful.

I agree with you 100% to not compromise on type safety. It's what's awesome about your work with zodios... it practically feels like type safety is a "brand guarantee".

I think the reliance on decorators has emerged as a bit of a weak spot for NestJS and its really too bad that decorators in general can't be made more type safe within the confines of TypeScript as it exists today.

I figure the maintainers of NestJS are OK with it because they seem to be OK with looser types than we are. For example, for the longest time a project started with nest new wasn't in strict mode (maybe even still? I use a different boilerplate for new projects) and the framework's source code could be stronger typed in various areas as well. They do like their any. I don't like how verbose param decorators can get with all the extra type declarations. Plus zillions of decorators can sometimes really clutter up code especially in entity classes.

Perhaps you're right that a giant decorator is the way to go.

Or perhaps an ambitious future that brings DI-or-DI-like (for TS there are some approaches like typed-inject), modularity, and a Nest-like request lifecycle to express... a true type-safe replacement for Nest :P