Tsoa: Support enums

Created on 25 Jul 2016  Â·  21Comments  Â·  Source: lukeautry/tsoa

Acceptance Criteria:

  • Enum properties/return types should generate valid swagger enum types
  • Routing layer should validate enums
enhancement help wanted

Most helpful comment

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
https://github.com/lukeautry/tsoa/issues/6#issuecomment-234816265, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIXUACHjNUQlYCqctcorqtKXO6XZKti9ks5qZA3sgaJpZM4JTt7o
.

All 21 comments

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.

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
https://github.com/lukeautry/tsoa/issues/6#issuecomment-234816265, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIXUACHjNUQlYCqctcorqtKXO6XZKti9ks5qZA3sgaJpZM4JTt7o
.

@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.

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

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

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

for example:

type Auth = "Facebook" | "Google" 

@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.

@lukeautry which branch is it? None of the branch names seemed obvious
On Sun, Jan 8, 2017 at 19:01 Luke notifications@github.com wrote:

@maxcan https://github.com/maxcan Yeah, I have a branch going to
implement that exact thing; the issue you opened #39
https://github.com/lukeautry/tsoa/issues/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
https://github.com/lukeautry/tsoa/issues/6#issuecomment-271203700, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAneTBdt1FI1G3pBuKLXUoG7raipu_fsks5rQaMhgaJpZM4JTt7o
.

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 notifications@github.com
wrote:

@lukeautry which branch is it? None of the branch names seemed obvious
On Sun, Jan 8, 2017 at 19:01 Luke notifications@github.com wrote:

@maxcan https://github.com/maxcan Yeah, I have a branch going to
implement that exact thing; the issue you opened #39
https://github.com/lukeautry/tsoa/issues/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
https://github.com/lukeautry/tsoa/issues/6#issuecomment-271203700, or
mute
the thread
AAneTBdt1FI1G3pBuKLXUoG7raipu_fsks5rQaMhgaJpZM4JTt7o>
.

>

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lukeautry/tsoa/issues/6#issuecomment-271211666, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIXUAFT6jVQBUzdQyQ7iJXTWZaXsvw9yks5rQb79gaJpZM4JTt7o
.

@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

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.

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

@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

@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?

what do you mean by "pathable"?

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

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?

@lukeautry I'd love to submit a PR regarding enums-as-union-types and alias types, yet it bases on https://github.com/lukeautry/tsoa/pull/77 and https://github.com/lukeautry/tsoa/pull/75 so I'd like to ask to take a look on those

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

image

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

in this block filter its empty because

the typename no is SafeArray

image

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

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

Was this page helpful?
0 / 5 - 0 ratings