Last 12 weeks ยท 92 commits
5 of 6 standards met
PR https://github.com/honojs/hono/pull/4393 improved the ability to get accurate types for specific status codes. While this is a great improvement on its own, it is causing an issue in my project. In my project, we centrally manage 4xx and 5xx errors using a customized fetch function. Our design allows individual UI components to handle only the success cases. Previously, this meant our UI components were type-safe without needing to explicitly check the response code. However, since v4.10.0 (where https://github.com/honojs/hono/pull/4393 was released), we can no longer resolve the types without checking status or ok in each UI component. As a result, we are forced to add these checks to every single API call site. This negatively affects the codebase by reducing readability (due to increased boilerplate) and increasing the bundle size. Is there a way to maintain type safety without manually checking status or code, just as we were able to do before? Any advice would be appreciated. _Originally posted by @baseballyama in https://github.com/honojs/hono/discussions/4575_
The author should do the following, if applicable [x] Add tests [x] Run tests [x] to format the code [ ] Add TSDoc/JSDoc to document the code "prefix" option in Bearer Auth middleware is interpolated directly into without escaping. This may cause SyntaxError crashes or unintended pattern matching when "prefix" contains regex metacharacters. e.g., (, ), ., +, ... ...
Repository: honojs/hono. Description: Web framework built on Web Standards Stars: 29328, Forks: 976. Primary language: TypeScript. Languages: TypeScript (99.4%), JavaScript (0.6%), Dockerfile (0%), HTML (0%). License: MIT. Homepage: https://hono.dev Topics: aws-lambda, bun, cloudflare, cloudflare-workers, deno, npm, router, typescript, web-framework. Latest release: v4.12.7 (3d ago). Open PRs: 84, open issues: 258. Last activity: 1d ago. Community health: 75%. Top contributors: yusukebe, usualoma, EdamAme-x, watany-dev, ryuapp, nakasyou, metrue, exoego, sor4chi, yasuaki640 and others.
TypeScript
What is the feature you are proposing? Certain frameworks (eg: fastify) provide response validation for success or error payloads. Is there support for such feature in hono? If not, is it something planned? Context Apart from obvious advantages like schema-first approach, this feature would greatly help securing API internals. For example, when you have multiple unique IDs for DB records and you want to make sure that only IDs are ever returned without accidentally leaking IDs.
What version of Hono are you using? hono: 4.11.7 @hono/node-server: 1.19.9 What runtime/platform is your app running on? (with version if possible) Bun 1.2.19 (Linux) Also reproduced on Node.js v22.17.1 What steps can reproduce the bug? Cause When @hono/node-server's serve() runs with overrideGlobalObjects: true (the default), it replaces globalThis.Request and globalThis.Response with lightweight polyfills. Libraries that validate objects via instanceof Request or instanceof Response break silently because the objects returned by native fetch() were constructed with the original classes, not Hono's replacements. Reproduce run the bun test to reproduce test file What is the expected behavior? serve() should not break instanceof checks in third-party libraries. Returning the same Request/Response object from middleware callbacks should work regardless of overrideGlobalObjects. What do you see instead? Error: onResponse: must return new Response() when modifying the response at coreFetch (openapi-fetch/dist/index.mjs:165:23) Additional information _No response_
When a filename with an upper/mixed-case extension is provided to getMimeType, it currently returns an undefined value which causes the static middleware to return a Content-Type of . This PR normalizes upper/mixed-case file extensions during the check so that they can be properly matched to the MIME type map. The author should do the following, if applicable [x] Add tests [x] Run tests [x] to format the code [x] Add TSDoc/JSDoc to document the code