Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fastify reply functions wrongly typed #133

Closed
2 tasks done
g0di opened this issue Apr 21, 2023 · 3 comments · Fixed by #134
Closed
2 tasks done

Fastify reply functions wrongly typed #133

g0di opened this issue Apr 21, 2023 · 3 comments · Fixed by #134

Comments

@g0di
Copy link
Contributor

g0di commented Apr 21, 2023

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the issue has not already been raised

Issue

Hi folks,

Looking at typings for fastify reply decorations added by this library in httpError.d.ts

// Line 103
export type HttpErrorReplys = {
  getHttpError: (code: HttpErrorCodes, message?: string) => void;
} & Record<HttpErrorNames, (msg?: string) => void>;

it looks like that those functions (rep.internalServerError('') for example) should return void.

However, looking at the implementation in index.js

// Line 47
fastify.decorateReply(httpError, function (message) {
  this.send(httpErrors[httpError](message))
  return this
})

it looks like that the reply object is returned after calling send function.

Could it be possible to align the typings so I can do the following in my code without a 'await' has no effect on the type of this expression.ts(80007) message and ESLint being mad?

fastify.get('/', { 
  async handler(req, rep) {
    return await rep.internalServerError('Oops')
  }
}

image

Thanks

@Eomm
Copy link
Member

Eomm commented Apr 22, 2023

Thanks for reporting!
Would you like to send a Pull Request to address this issue? Remember to add unit tests.

@g0di
Copy link
Contributor Author

g0di commented Apr 24, 2023

I'll try if I got some spare time. About tests, what kind of tests you would? Just ensuring the functions actually return the reply object and not void?

@mcollina
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants