Last 12 weeks · 12 commits
2 of 6 standards met
Repository: honojs/node-server. Description: Node.js Server for Hono Stars: 605, Forks: 85. Primary language: TypeScript. Languages: TypeScript (98.7%), JavaScript (1.2%), HTML (0%). License: MIT. Homepage: https://hono.dev Topics: hono, http-server, nodejs, server. Latest release: v1.19.11 (1w ago). Open PRs: 13, open issues: 30. Last activity: 1d ago. Community health: 37%. Top contributors: yusukebe, usualoma, tangye1234, tavvy, Jayllyz, nakasyou, tsctx, beeequeue, alexfriesen, alumowa and others.
TypeScript
What version of Hono are you using? : 4.11.7 : 1.19.9 What runtime/OS are you seeing the problem on? Bun 1.2.19 (Linux) Also reproduced on Node.js v22.17.1 What steps can reproduce the bug? When 's runs with (the default), it replaces and with lightweight polyfills. Libraries that validate objects via or break silently because the objects returned by native were constructed with the original classes, not Hono's replacements. Minimal reproduction with : Upstream mock (any server returning JSON on ). Trigger: Bun test proving the issue What is the expected behavior? should not break checks in third-party libraries. Returning the same / object from middleware callbacks should work regardless of . What do you see instead? internally validates middleware returns with: The object returned by native was constructed with the original class, but after , checks against Hono's replacement polyfill — which fails. Root cause 's replaces and with lightweight alternatives. Any library relying on or to validate objects created by the native will break, because native fetch constructs objects using the original constructors, not the replacements. Additional context This affects any library that uses or for validation, not just . The pattern is common in HTTP middleware ecosystems (, , custom fetch wrappers, etc.).
I migrated build tool from tsup to tsdown. I ran according to tsdown's Migration Guide. I modified the tsdown configuration to align with the paths defined in package.json. I added a separate ci-build job running on Node.js 24, since tsdown (Rolldown) requires node:util#styleText which is not available in Node.js 18.
Summary I migrated our test framework from Jest to Vitest, considering aspects such as performance and development experience. Consideration In the test case 'should return undefined if stream is closed', the test for the function is failing. However, the following ReadableStream should be rejected when is executed, and I believe the verification method for is incorrect. However, when I ran the tests with Jest, this test case passed, and I don't understand why. For now, I'm verifying that an exception is thrown by ... I'd like you to think with me about what this test case should ideally be.