Support enums about tsoa

[lukeautry]

I think the string representation that you've proposed is ideal. The number
representation is basically meaningless from a human readability standpoint.
On Jul 24, 2016 9:14 PM, "Dave Leaver" [email protected] wrote:

For my uses I'd like to declare an enum and have the field be the string
values

enum ResultType {
Success,
FailureNoPermission
}

Should result in swagger like:

"type": "string","enum": [ "Success", "FailureNoPermission" ],

Not sure if other people would like the numeric values.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIXUACHjNUQlYCqctcorqtKXO6XZKti9ks5qZA3sgaJpZM4JTt7o
.

[egandro]

You can try using this:

export type CaseEnum = "Unchanged" | "Capitalized" | "FirstLetterUppercase" | "CamelCase" | "PascalCase" | "Lower" | "Upper";

export const CaseEnum = {
Unchanged: "Unchanged" as CaseEnum,
Capitalized: "Capitalized" as CaseEnum,
FirstLetterUppercase: "FirstLetterUppercase" as CaseEnum,
CamelCase: "CamelCase" as CaseEnum,
PascalCase: "PascalCase" as CaseEnum,
Lower: "Lower" as CaseEnum,
Upper: "Upper" as CaseEnum
};

It feels like an enum - but it's actually a class/string

[danzel]

For my uses I'd like to declare an enum and have the field be the string values

enum ResultType {
    Success,
    FailureNoPermission
}

Should result in swagger like:

"type": "string",
"enum": [ "Success", "FailureNoPermission" ],

Not sure if other people would like the numeric values.

[lukeautry]

@danzel Just wanted to provide an update here; enum support hasn't been straightforward, at least for the routing side of things. Generating the correct swagger spec is a straightforward, but wiring up the autogenerated routes to 1) convert strings to their enum values and 2) validate enum values takes a bit more work. Hope to have something in the next week or so.

[danzel]

Thanks, no hurry the string work around is fine :)

[maxcan]

@lukeautry would it be easier to support string literal types instead of enums?

for example:

type Auth = "Facebook" | "Google" 

[lukeautry]

@maxcan Yeah, I have a branch going to implement that exact thing; the issue you opened #39 is caused by the inability to parse a type alias/string literal type.

Feel free to take a stab at it though, it'll probably be next week sometime before it can be completed.

[maxcan]

@lukeautry which branch is it? None of the branch names seemed obvious

…

On Sun, Jan 8, 2017 at 19:01 Luke ***@***.***> wrote: @maxcan <https://github.com/maxcan> Yeah, I have a branch going to implement that exact thing; the issue you opened #39 <#39> is caused by the inability to parse a type alias/string literal type. Feel free to take a stab at it though, it'll probably be next week sometime before it can be completed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAneTBdt1FI1G3pBuKLXUoG7raipu_fsks5rQaMhgaJpZM4JTt7o> .

[lukeautry]

Sorry Max, didn't mean to imply it was a remote branch, just a local branch that's exploring the idea of parsing string literal types. On Mon, Jan 9, 2017 at 12:00 AM, Max Cantor <[email protected]> wrote:

…

@lukeautry which branch is it? None of the branch names seemed obvious On Sun, Jan 8, 2017 at 19:01 Luke ***@***.***> wrote: > @maxcan <https://github.com/maxcan> Yeah, I have a branch going to > implement that exact thing; the issue you opened #39 > <#39> is caused by the inability > to parse a type alias/string literal type. > > Feel free to take a stab at it though, it'll probably be next week > sometime before it can be completed. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#6 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AAneTBdt1FI1G3pBuKLXUoG7raipu_fsks5rQaMhgaJpZM4JTt7o> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIXUAFT6jVQBUzdQyQ7iJXTWZaXsvw9yks5rQb79gaJpZM4JTt7o> .

[maxcan]

@lukeautry is it worth using it as a starting point? If not, I can start off master, just tell me where to look in the code

[adhamhf]

hey @lukeautry I'm only interested in swagger support... any chance you could share the code that gets enums to work with swagger? I could then use it in a fork.

[alexey-pelykh]

@maxcan do you plan to add support for using string literal types as @path arguments?

[maxcan]

@alexey-pelykh I'm actually not using tsoa at the moment - jumped over to the graphql dark side so I won't be making any more changes. Happy to give some tips if you want to take it up though.

Max

[alexey-pelykh]

@maxcan yeah, I have no choice then :) I've looked through the code more or less, string literal as "pathable" type - just something that was missed out or there was a reason for not doing that?

[maxcan]

what do you mean by "pathable"?

[alexey-pelykh]

union (string literals) fails over here https://github.com/lukeautry/tsoa/blob/master/src/metadataGeneration/parameterGenerator.ts#L128
So it's impossible to use type test = 'a' | 'b'; in Header, Query or Path parameters. I do hope to address that soon

[maxcan]

ah ok, I see what you mean. no, I never added support for that. I imagine i shouldn't be too difficult though, just not on my radar. maybe use the PR above as a guide?

[alexey-pelykh]

@lukeautry I'd love to submit a PR regarding enums-as-union-types and alias types, yet it bases on #77 and #75 so I'd like to ask to take a look on those

[j-ibarra]

Hello, any update for this support, I'm actually trying to add type and enumeration to the response body, but it fails in TypeResolver, the enumeration name (Merchant Status) is not the same as SafeArray

export enum MerchantStatus {
  active = 'active',
  pending = 'pending',
}

export class User {
  uid: string;
  merchantStatus: MerchantStatus;
}

Unhandled rejection Error: No matching model found for referenced type MerchantStatus. If MerchantStatus comes from a dependency, please create an interface in your own code that has the same structure. Tsoa can not utilize interfaces from external dependencies. Read more athttps://github.com/lukeautry/tsoa/blob/master/docs/ExternalInterfacesExplanation.MD

return (modelTypeDeclaration.name as ts.Identifier).text === typeName;

in this block filter its empty because

the typename no is SafeArray

[WoH]

Could you tell me if this issue still applies to the v3 beta releases?

[j-ibarra]

Could you tell me if this issue still applies to the v3 beta releases?

I just upgraded to version 3.0.4, and the problem has been solved thanks very much