vholik / medusa-custom-attributes

Plugin that extends MedusaJs with custom attributes API
88 stars 20 forks source link

Error: "an unknown value was passed to the validate function" for single, multi & boolean types #23

Closed molhar closed 7 months ago

molhar commented 7 months ago

I've cloned the plugin to add some custom functionality however, with a fresh install with no modifications it yields the error "an unknown value was passed to the validate function" when attempting to add a single, multi or boolean type attribute.

For some reason the range type works fine.

Is there possibly a simple explanation? The class-validator code is a labryinth to debug.

molhar commented 7 months ago

Bit more digging into what's happening in class-validator. The problem seems to be when the nested validation of objects in values happens.

nestedValidations() calls execute() with an object from values but a targetScheme of AdminPostAttributeReq, which consequently doesn't find any targetMetadatas and consequently rejects the object as an unknown value.

molhar commented 7 months ago

A bit more info here. If I modify the create-attribute.ts endpoint to explicitly perform a plainToClass transformation with enableImplicitConversion: true, then everything works fine e.g.

    const transformed = plainToClass(AdminPostAttributeReq, req.body, {
      enableImplicitConversion: true,
    });

    const validated = await validator(AdminPostAttributeReq, transformed);

I'm sure the conversion should be happening automatically, but struggling to see why it isn't.

vholik commented 7 months ago

Can you share your repo so I can see what can be a problem?

molhar commented 7 months ago

I've just worked it out. I'm linking in the plugin to my project with yarn add medusa-custom-attributes@link:<path-to-plugin> which resulted in two different instances of class-transformer being used, meaning the global metadata stash wasn't available when called from medusa's validator().

Removing node_modules/class-transformer from medusa-custom-plugin fixes the issue, however is there a better approach to dealing with this issue during development?

molhar commented 7 months ago

I ended up including the package as a subtree under a workspace in my monorepo which seems to work fine. I've created a string attribute type based off of int attribute type so that you can enter an arbitrary text values for an attribute. Happy to share back if this might be of any use.