Is it possible to define schema for custom tags?

[jindong-zhang-git]

Summary

Hi team, I have a custom tag !include with 2 properties source and path.

Usage case:

object:
  <<: !include
    source: './abc/xyz'
    path: anyField

For now I have added it into yaml.customTags in settings: "yaml.customTags": ["!include mapping"].

No errors. Great!

But I hope to add additional checks on it, such as tagging source and path as required. Is it possible? And how should I to implement it? Thanks.

[evidolob]

But I hope to add additional checks on it, such as tagging source and path as required. Is it possible? And how should I to implement it? Thanks.

That is not possible, as we use JSON Schema to validate yaml, and JSON schema doesn’t have any notion for yaml tags.

Maybe we can add non standard extension for JSON Schema to add definition/validation for yaml tags. @gorkem WDYT?

[jindong-zhang-git]

@evidolob Thanks for your reply.

Since I can't check it, can I ignore this fragment during validation?

<<: !include
  source: './abc/xyz'
  path: anyField

[evidolob]

Unfortunately no, we don’t have such feature

[jindong-zhang-git]

Oops, what a bad news.

Currently I meet some issue on validating yaml with !include tag:

object:
  <<: !include
    source: './abc/xyz'
    path: anyField
  objectProperty: xxx

In above example, the validator will see source and path as object's properties incorrectly. And obviously object doesn't support these two properties. So that there will be a validation error.

For me if I can tell validator that please don't check fragments start with <<, it's enough to solve my problem. Any ideas?

[gorkem]

@evidolob I suppose we can extend JSON schema, but I am not sure how common the use-case is at the moment. Let's gather more feedback on the usage before we decide.

<< is not suitable for use as a prefix for ignoring fragments as it has a special meaning.

[jindong-zhang-git]

Thanks @gorkem @evidolob, it's great if can support this feature.

But this issue blocks my work now. I wonder is there a way to do some customization on yaml parsing/validating to solve my problem? (I am building my own vscode extension depends on yours)

[airtonix]

If we can't validate it then the use case will remain uncommon.

Once we can validate it, the use case will become more common.

My view is that since tags are a core feature of yaml, then the validator should have a way to describe how to validate them.