How to force using JSONSchema decorator from parent?

[juiceo]

From the docs:

JSONSchema decorators also flow down from parent classes into inherited validation decorators. Note though that if the inherited class uses JSONSchema to redecorate a property from the parent class, the parent class JSONSchema gets overwritten - i.e. there's no merging logic.

This makes sense in theory, but in reality the fact that the parent class decorator doesn't take precedence is a bit backwards, I feel.

For example, I have this kind of class representing an object of localized strings:

// simplified

@JSONSchema({
  title: 'Localized string',
  description: 'An object of translations'
})
class LocalizedString {
  en: string;
  de: string;
  fr: string;
}

This field is used in many of my other classes, for example for the name of a product:

// simplified

class Product {
  @JSONSchema({
    title: 'Product name',
    description: 'The name of the product and its translations.'
  })
  name: LocalizedString;

  ...
}

With this kind of setup, the resulting JSON schema has the name field of the product described with the generic title and description from LocalizedString instead of the one I define in Product. I think it should work in exactly the opposite preference, as the case where I'm using it within a Product object is the more specific case, if you see what I mean.

One solution would be to just remove the JSONSchema decorator from LocalizedString entirely, but I would still like to have at as I have a generic Model reference in my docs where it would be useful.

Question is:

• Is there a way to do what I want currently?
• If not, what do you think it would require to get a workable solution to this?

[juiceo]

I know there's this section in the docs:

Alternatively JSONSchema can take a function of type (existingSchema: SchemaObject, options: IOptions) => SchemaObject. The return value of this function is then not automatically merged into existing schema (i.e. the one derived from class-validator decorators). Instead you can handle merging yourself in whichever way is preferred, the idea being that removal of existing keywords and other more complex overwrite scenarios can be implemented here.

However I'm a bit lost regarding how to actually use this, if you can help at all. Would be great to have a code example of this functionality in the docs as well.

[epiphone]

The example you posted doesn't contain any inheritance so the problem probably lies somewhere else.

Can you post the exact JSON Schema you're getting in your use case? My guess is that in your example case we end up with a Product schema of something like

{
  "properties": {
    "name": {
      "$ref": "<ref to LocalizedString schema>",
      "description": "The name of the product and its translations."
    }
  }
}

And since earlier JSON Schema drafts ignore all other than $ref properties in a reference schema (source), description gets dropped.

OpenAPI's reference objects likewise cannot be extended with additional properties and any properties added SHALL be ignored. https://swagger.io/specification/#reference-object

If that's the case, the solution is to either try some of the creative workarounds mentioned here https://stackoverflow.com/questions/33565090/json-schema-property-description-and-ref-usage or to introduce some sort of complex duplication logic into the library. Or we could wait for OpenAPI v3.1.0 which will finally support the latest JSON Schema draft in its entirety :slightly_smiling_face: