Skip to content

types: allow any return value for error - #222

Open
sirlancelot wants to merge 2 commits into
fastify:mainfrom
sirlancelot:patch-1
Open

sirlancelot wants to merge 2 commits into
fastify:mainfrom
sirlancelot:patch-1

Conversation

@sirlancelot

Copy link
Copy Markdown

Checklist

Description

The return value of the errorResponse config option function gets passed directly to reply.send and as such can support a wide range of possible values. Since the documentation encourages using this option to supply one's own error shape, it shouldn't make assumptions about the type, so I've set it to unknown in order to fix the type error I get when supplying my own error shape.

Signed-off-by: Matthew Pietz <sirlancelot@users.noreply.github.com>
@Fdawgs
Fdawgs requested a review from Copilot November 6, 2025 20:03

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot wasn't able to review any files in this pull request.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@Fdawgs Fdawgs changed the title Allow any return value for error types: allow any return value for error Nov 28, 2025
@Fdawgs
Fdawgs requested a review from a team November 28, 2025 12:00

@is2ei is2ei left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Fdawgs Fdawgs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @sirlancelot, could you please add an associated test?

Comment thread types/index.d.ts
keys: Set<string> | string[];
auth?: (key: string, req: FastifyRequest) => boolean | Promise<boolean> | undefined;
errorResponse?: (err: Error) => { error: string };
errorResponse?: (err: Error) => unknown;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sirlancelot

Sorry for requesting changes after approving.

Could you add more test cases in addition to the existing string-based fixture using err.message? Since we now support returning unknown instead of string, it would be helpful to cover those cases as well.

For example:
https://github.com/sirlancelot/fastify-bearer-auth/blob/patch-1/types/index.test-d.ts#L6-L13

const pluginOptions: FastifyBearerAuthOptions = {
  keys: new Set(['foo']),
  auth: (_key: string, _req: FastifyRequest) => { return true },
  errorResponse: (err: Error) => { return { error: err.message } },
  contentType: '',
  bearerType: '',
  addHook: false
}

@sirlancelot sirlancelot Dec 7, 2025 •

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not exactly sure what sort of testing is possible for unknown types. I think that's the point of unknown. All errors in JavaScript start out as unknown or any, depending on configuration, it's up to the implementation to determine what type it actually is.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sirlancelot

Thanks for your reply.

How about adding a test case using primitive types?
This would ensure that the return value accepts types other than just string.

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 this pull request may close these issues.

4 participants