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

feat(zod-openapi): infer env from routeMiddleware #807

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

oberbeck
Copy link

@oberbeck oberbeck commented Nov 5, 2024

This PR is my initial proposal for adding type inference support for the zod-openapi middleware package, improving type safety when using middleware within the router definition.

Example usecase:

const app = new OpenAPIHono<{Variables: { too: Symbol }}>()
app.openapi(
createRoute({
method: 'get',
path: '/books',
middleware: [
createMiddleware<{
Variables: { foo: string }
}>((c, next) => {
c.set('foo', 'abc')
return next()
}),
createMiddleware<{
Variables: { bar: number }
}>((c, next) => {
c.set('bar', 321)
return next()
}),
] as const,
responses: {
200: {
description: 'response',
},
},
}),
(c) => {
c.var.foo
c.var.bar
c.var.too
type verifyFoo = Expect<Equal<typeof c.var.foo, string>>
type verifyBar = Expect<Equal<typeof c.var.bar, number>>
type verifyToo = Expect<Equal<typeof c.var.too, Symbol>>
return c.json({})
}
)

Background

I'm fairly new to HonoJS, but I've been very excited to explore its potential, especially the zod-openapi integration. However, I noticed that middleware types seem to be dropped when used alongside the OpenAPI package, which can impact type consistency and developer experience.

Potentially resolving:

Potential alternative

Thank you for considering this suggestion! Please feel free to suggest improvements or adjustments to align it with the project's requirements.

Copy link

changeset-bot bot commented Nov 5, 2024

⚠️ No Changeset found

Latest commit: aca9bfd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@oberbeck oberbeck marked this pull request as ready for review November 5, 2024 14:22
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.

1 participant