tsoa: Error: No matching module declarations found for express.

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

Build my spec.

Current Behavior

Error: No matching module declarations found for express.

Steps to Reproduce

    @Get('/local')
    private local(@Request() req: express.Request, res: express.Response): void {
    }

This works:

    @Get('/local')
    private local(@Request() req: express.Request): void {
    }

Context (Environment)

Version of the library: 3.0.8 Version of NodeJS: 10

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

Detailed Description

Build my spec.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 17

Most upvoted comments

Idk what to tell you. tsoa is focused on providing validation, which won’t work if you pull stuff off the request directly. tsoa is heavily built around the idea of well designed, complete, accurate response docs, which you’re actively trying to fight in order to keep the subpar API express provides out of the box.

I’d love to have a magic bullet here, but bare express applications are incompatible with tsoa’s philosophy of providing a good interface on top of these lower-level frameworks. Express has a great API if you want to quickly prototype but you can’t efficiently build what I consider to be good APIs (+ specification) without additional abstractions or bending over backwards and some mental gymnastics on top.

If you don’t want to buy into that, sure, we even give you the tools to shoot yourself in the foot (@Request, req.res) if you want to, but I just don’t think that we should make if as comfortable as possible.

I would agree that the migration could be easier if we were to allow @Res() res: TsoaResponse<Code, ResponseType>, but if you want to keep (req: express.Request, res: express.Response) without the willingness to even change that to

methodName(@Request req: ExpressRequest): void {
  //...
  // res.send -> req.res.send()
}

(until “properly” typing this with a returnType and returning instead of using req.res.send) that’s just not what tsoa does.

WoH on May 8, 2020

I am not sure if tsoa supports this. You might be able to inject the response if you use a custom routes template. How do you document the response, if not by returning a typed Promise? Do you use @Response()?

I’ve recently converted an older codebase to TSOA. I did it controller by controller though, to see how much effort it would be. After seeing that it was actually quite quick to turn the old endpoint functions into Promise-returning tsoa style functions, I just migrated all of them. 🤷‍♂️

endor on May 7, 2020