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

Provide defineErrorHandler when writing a nitro error handler #1922

Closed
1 task done
passionate-bram opened this issue Nov 17, 2023 · 1 comment · Fixed by #1923
Closed
1 task done

Provide defineErrorHandler when writing a nitro error handler #1922

passionate-bram opened this issue Nov 17, 2023 · 1 comment · Fixed by #1923

Comments

@passionate-bram
Copy link
Contributor

Describe the feature

A lot of configurable functionality in nitro uses the "definer" pattern (defineNitroConfig, definePlugin, etc.) to help users make type-safe definitions, provide IDE completions and you could even backport breaking changes by adding logic to the definer function that upgrades a definition passed to it.

I'd say it is probably one of the most important features, as it creates a very robuust workflow for writing (runtime) code.

Strangely enough there is no such definer function for an error handler.
Instead there is the following example set by the docs:

import type { NitroErrorHandler } from 'nitropack'

export default <NitroErrorHandler> function (error, event) {
  event.res.end('[custom error handler] ' + error.stack)
}

Link to NitroErrorHandler definition

I believe this to be a mistake.
The error handler (as far as I can tell) has the same runtime as event handlers, plugins and so on.

The definer would look something like the following:

export function defineErrorHandler(handler: NitroErrorHandler) : NitroErrorHandler {
  return handler;
}

Required changes:

  1. Add the definer function
  2. Make the definer part of the auto-imports
  3. Update the documentation of config#error-handler

Additional information

  • Would you be willing to help implement this feature?
@passionate-bram
Copy link
Contributor Author

As an aside; perhaps a dedicated definers.ts is preferable to locate all "definers" together.
The new file would pull in types needed for the function signatures from the current parts of the codebase they reside.
In terms of developer workflow this provides a central location for all definable things nitro has, and also links them up to the parts of the nitro codebase that implement that feature. That seems preferable to me compared to the current situation where these definers are sprinkled in all sorts of locations.

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

Successfully merging a pull request may close this issue.

1 participant