Thanks for this package, it has been extremely helpful in one of my projects at work!
The only limitation I've run into that has cause me a bit of grief is the lack of support for ECMA-262 regular expressions. My specific use case is that I want to exclude strings that end with a certain file name.
{
"type": "string",
"description": "The path to an action's folder. Must begin with either `./` or `../`. Must not include `action.jsonc`.",
"pattern": "^\\.{1,2}\\/.+(?<!action\\.jsonc)$"
}I could, of course, write some custom code to enforce that. However, then we'd lose access to the excellent validation error highlighting in VS Code for that particular part of the schema.
I've read through the discussion in #47 , and it seems that the only barrier here is in importing an ECMA-262 compatible regular expression library. If that's right, it seems like a small price to pay to improve interoperability.
Thoughts?
Thanks for this package, it has been extremely helpful in one of my projects at work!
The only limitation I've run into that has cause me a bit of grief is the lack of support for ECMA-262 regular expressions. My specific use case is that I want to exclude strings that end with a certain file name.
{ "type": "string", "description": "The path to an action's folder. Must begin with either `./` or `../`. Must not include `action.jsonc`.", "pattern": "^\\.{1,2}\\/.+(?<!action\\.jsonc)$" }I could, of course, write some custom code to enforce that. However, then we'd lose access to the excellent validation error highlighting in VS Code for that particular part of the schema.
I've read through the discussion in #47 , and it seems that the only barrier here is in importing an ECMA-262 compatible regular expression library. If that's right, it seems like a small price to pay to improve interoperability.
Thoughts?