DTO is not a class, all fields typed as optional about nestjs-zod HOT 2 CLOSED

Can't really say much regarding the first issue, but in regards to the second issue where all properties are presented as being optional, this can be solved by setting strictNullChecks to true in your tsconfig.json file.

Update: Actually zod's documentation requires you to set strict: true in your tsconfig.json, you can read it here.

from nestjs-zod.

Thanks, @xrebelox - I changed the strict level and the second issue is gone. I never really ever had the need to enforce strict mode before, although it is recommended. I'm just stubborn.

As for the first issue, I've found a fix:

In the src/pipe.ts module, within the transform method, there's this line:

return validate(value, metatype.schema, createValidationException)

As expected, if the validation passed, the object is returned. However, I kind of hacked the JS code directly, and I changed it to:

const result = validate(value, metatype.schema, createValidationException)
return Object.assign(new metatype(), result)

This creates a class instance of the same shape as the object. Since the DTO classes are created on-the-fly, this is safe to do. However, with a public library the choice on whether or not to transform the object to a class instance should be left to the end user, as it is in Nest's native SerializerInterceptor implementation (which uses class-transformer under the hood)

The metatype value will always be the class constructor reference to whatever the end-user adds as the DTO type.

This begs the question on WHERE to set this user configurable value. The best option would be to add an options object directly to the interceptor's constructor like so:

{
  provide: APP_INTERCEPTOR,
  useValue: new ZodSerializerInterceptor({ transform: true }),
}

Of course, the interceptor's constructor has an @Inject for the Reflector class so there are ways around this, but it should be noted that the Reflector class doesn't always need to be injected, and can be instantiated normally, as it's just a utility class with no DI of its own.

const reflector = new Reflector()

If you still prefer to inject it, there are ways to do that as well:

{
  provide: APP_INTERCEPTOR,
  inject: [Reflector],
  useFactory: (reflector: Reflector) => 
     new ZodSerializerInterceptor(reflector, { transform: true }),
}

I should note that for many use cases, the object is just fine and classes are not needed. However, this would be more of a semantic choice. If the type is defined as a certain class type, then the resulting value should conform to the class API specification including all the methods and accessors. This is why it should be the choice of the implementing party.

I also notice there is no top-level module to initialize. This is also a good way to introduce user-specific configuration for all the moving parts to have access to.

There's no contributing guide, so I'm curious as to the author's preferred protocols regarding PR's and such. I have loads of experience building NestJS libraries (all in-house libraries, but experience none the less), so I can make meaningful contributions to this project if it's welcome.

Cheers.

from nestjs-zod.