Wolfgang Hobmaier

Please open up a PR at https://github.com/tsoa-community/docs

Take a look around this: https://github.com/lukeautry/tsoa/blob/ea976ee5cac9edba0a2fbc9eb8d2729c4237f491/packages/cli/src/routeGeneration/templates/express.hbs#L199

@meehawk I referenced the function that needs to be changed. If the `data` is a buffer or a typed array, tsoa should not call `res.json` with the data, but instead...

Strings should be fine here. While it may not look great, the validation layer should currently support casting (default) strings to, i.e. numbers. Other way around is not supported, however,...

I mean, if we were to beak stuff, it'd be now, so I'm down to discuss this. Checking the test suite, we don't use default strings any where, I assume...

I'll summarize the results from the other issue: All JsDoc annotations that allow for parameters should JSON.parse these parameters to ensure we can distinguish based on data type. Because this...

@jfrconley are you interested in implementing this? This and #634 are the last changes I'm considering to bring into tsoa 3.

According to the rules, this string should: 1: Be taken from the JSDoc (it's a string there, `'` used to indicate that): `'```"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"```'` 2. Triple backslash escaped: `'"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"' ` 3....

> 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 escape character. This is what causes parsing to fail. That's what I was counting on. But...

I think for now, I'd agree with any improvements that treat default like example and parse these Annotations (ideally supporting triple backslashes), while the other annotations remain untouched.