John Conley

my issue is that openapi spec generated is not correct. This makes third party software such as Redoc show bad examples.

Sure, this shouldn't take too long

@WoH Looks like escape characters in strings will break JSON parsing, which kinda breaks RegEx. We might need to think a little bit more about options. EDIT: For example, the...

There are multiple issues. The original regex ([a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$) would not be equivalent to the final regex (^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$). Additionally, JSON.parse would effectively look like `JSON.parse('"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$"')` as JSDOC would preserve the original...

@WoH Currently only the @pattern tag supports backtick escaping, but this could be expanded. Because @example is run directly through JSON parse, we'll need to decide what escaping should actually...

I definitely agree. We could support this by just handling stripping surrounding backticks before JSON parse, but then you would have to quote string examples inside the surrounding back ticks....

That's a pretty good idea, would make the parsing behavior a lot more consistent. The general steps would be: * Surrounding triple backticks would be removed from all tag inputs...

@pattern specifically would be a problem in that case as Regex might cause JSON parse to fail

I would vote that we only support triple backticks for escaping. I think @pattern may be the only exception that would break JSON parse. We could also avoid this by...

My concern is the side effects of putting everything through JSON parse without an easy escape mechanism. Because triple backticks would only be used for escaping, strings would have to...