Support UndefinedKeyword

Sorting

• I’m submitting a …

  • bug report
  • feature request
  • support request

• I confirm that I

  • used the search to make sure that a similar issue hasn’t already been submit

Expected Behavior

Using @types/node 12.20.16 should still permit tsoa to generate routes.ts when using a custom error as below:

export interface CustomError extends Error {
  message: string;
  status: number;
}

@Route('GetTest')
export class GetTestController extends Controller {
  @Get('ThrowsError')
  @Response<CustomError>()
  public async getThrowsError(): Promise<TestModel> {
    throw {
      message: 'error thrown',
      status: 400,
    };
  }
}

Current Behavior

harrinm@C02D11F7MD6T:~/git/tsoa|master> yarn test
yarn run v1.22.4
$ yarn --cwd tests test
$ yarn clean && cross-env NODE_ENV=tsoa_test ts-node --require tsconfig-paths/register ./prepare.ts
$ rimraf dist fixtures/*/routes.ts fixtures/*/customRoutes.ts
↻ Starting Swagger Spec Generation...
There was a problem resolving type of 'Error'.
There was a problem resolving type of 'CustomError'.
Generate routes error.
 GenerateMetadataError: Unknown type: UndefinedKeyword
At: /Users/harrinm/git/tsoa/tests/node_modules/@types/node/globals.d.ts:127:127.
This was caused by 'string | undefined'
    at TypeResolver.resolve (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:309:13)
    at /Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:62:84
    at Array.map (<anonymous>)
    at TypeResolver.resolve (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:61:41)
    at TypeResolver.propertyFromSignature (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:890:137)
    at /Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:848:141
    at Array.map (<anonymous>)
    at TypeResolver.getModelProperties (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:848:98)
    at TypeResolver.getModelReference (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:622:29)
    at TypeResolver.getReferenceType (/Users/harrinm/git/tsoa/packages/cli/src/metadataGeneration/typeResolver.ts:563:30)

Possible Solution

Not sure.

I’ll at least be providing a PR to demo a failing test for it though.

Steps to Reproduce

• Update tests/package.json to "@types/node": "^12.20.16"
• Add @Response<CustomError>() to tests/fixtures/controllers/getController.ts
• yarn test

…or run the PR I’ll be putting up shortly to contrib a failing test demoing the problem.

Context (Environment)

Version of the library: master Version of NodeJS: 12.21.0

• Confirm you were using yarn not npm: [x]

Detailed Description

In @types/node 12.20.16, DefinitelyTyped’s added | undefined to a lot of fields, to prepare for the upcoming exactOptionalPropertyTypes setting in TypeScript 4.4.

An unfortunate side-effect is that now tsoa has trouble handling a number of built-in types, including Error, which is a problem for us when we use it like so: @Response<MyCustomError>()

[foglerek]

Hello, just to flag that we’re also running into this with types generated by ts-proto, which add | undefined to any optional properties — making it impossible to reference ts-proto-generated types as part of any type referenced in @Body or otherwise.

Could try to implement this, if you have any further pointers apart from the above.

[WoH]

This issue is a duplicate, but since TS 4.4 now really does differentiate, we should reconsider the support.