feat(deps)!: Update dependency @hono/node-server (1.19.14 → 2.0.4)

[its-miso]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@hono/node-server	^1.19.14 → ^2.0.0

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

honojs/node-server (@​hono/node-server)

v2.0.4

Compare Source

What's Changed

• fix: stub ws types to prevent them leaking in public types by @​BlankParticle in #​359

Full Changelog: honojs/node-server@v2.0.3...v2.0.4

v2.0.3

Compare Source

What's Changed

• chore(ci): update GitHub Actions versions by @​BlankParticle in #​352
• docs: Align the ServeStaticOptions comment with the current spec by @​kakkokari-gtyih in #​356
• fix: preserve headers mutated after raw Response construction by @​abdulmunimjemal in #​357

New Contributors

• @​kakkokari-gtyih made their first contribution in #​356
• @​abdulmunimjemal made their first contribution in #​357

Full Changelog: honojs/node-server@v2.0.2...v2.0.3

v2.0.2

Compare Source

What's Changed

• fix(serve-static): stop using file birthtime for Date header by @​usualoma in #​350
• fix: handle serveStatic stream fallback backpressure by @​usualoma in #​351

Full Changelog: honojs/node-server@v2.0.1...v2.0.2

v2.0.1

Compare Source

What's Changed

• fix: forward Hono response headers during WebSocket upgrade by @​gentamura in #​346

New Contributors

• @​gentamura made their first contribution in #​346

Full Changelog: honojs/node-server@v2.0.0...v2.0.1

v2.0.0

Compare Source

Now, we release the second major version of the Hono Node.js adapter 🎉 🎉 🎉

The Hono Node.js adapter is now up to 2.3x faster

v2 of the Hono Node.js adapter reaches up to 2.3x the throughput of v1 — that's the peak number, measured on the body-parsing scenario of bun-http-framework-benchmark. The other scenarios (Ping, Query) get a smaller but real boost too.

Install or upgrade with:

npm i @​hono/node-server@latest

v2

The Node.js adapter is going through a major version bump to v2. That said, the public API stays the same — the headline of this release is the large performance improvement described above.

What does the Node.js adapter do?

A quick refresher on what the Node.js adapter actually does — it exists so that Hono applications can run on Node.js. Hono is built on the Web Standards APIs, but you cannot serve those directly from Node.js. The adapter bridges the Web Standards APIs and the Node.js APIs, which is what lets a Hono app — and more generally a Web-Standards-style app — run on top of Node.js.

If you write the following code and run node ./index.js, a server starts up on localhost:3000. And it really is plain Node.js underneath.

import { Hono } from 'hono'
import { serve } from '@​hono/node-server'

const app = new Hono()
app.get('/', (c) => c.text('Hello World!'))

serve(app)

The early performance story

The very first implementation of the Node.js adapter looked roughly like this in pseudocode:

export const getRequestListener = (fetchCallback: FetchCallback) => {
  return async (incoming: IncomingMessage, outgoing: ServerResponse) => {
    const method = incoming.method || 'GET'
    const url = `http://${incoming.headers.host}${incoming.url}`

    // ...

    const init = {
      method: method,
      headers: headerRecord,
    }

    // app is a Hono application
    const res = await app.fetch(new Request(url, init))
    const buffer = await res.arrayBuffer()
    outgoing.writeHead(res.status, resHeaderRecord)
    outgoing.end(new Uint8Array(buffer))
  }
}

So the flow was:

• a request comes in as an IncomingMessage
• it gets converted into a Request object and handed to the app
• the Response returned by the app is written back to the outgoing ServerResponse

In diagram form:

IncomingMessage => Request => app => Response => ServerResponse

This is, frankly, inefficient. So whenever Hono went head-to-head with other Node.js frameworks we kept losing — all we could do was shrug and say "well, it's slow on Node.js."

Introducing LightweightRequest / LightweightResponse

The huge step forward that fixed this was a legendary PR from @​usualoma:

#​95

It made things up to 2.7x faster.

I previously wrote about this in detail in this post:

https://zenn.dev/yusukebe/articles/7ac501716ae1f7?locale=en

In short, the trick is wonderfully simple. It just follows the golden rule of performance tuning: don't do work you don't have to do. Lightweight versions of Request and Response are constructed and used first — and that path is fast. Only when something actually needs the contents of the Request, e.g. when you call req.json(), does a real new Request() get instantiated under the hood and used from then on. The result is fast, and behavior stays correct.

…but body parsing was still slow

"Fast" here was for a very simple "Hello World" benchmark — a GET that just returns text.

There are many ways to benchmark, but the one we tend to reach for is this:

https://github.com/SaltyAom/bun-http-framework-benchmark

It tests three scenarios: Ping, Query, and Body. Let's pit Hono against the major Node.js frameworks:

As you can see, the Body case is very slow. The handler being measured is essentially this:

import { Hono } from 'hono'
import { serve } from '@​hono/node-server'

const app = new Hono()

app.post('/json', async (c) => {
  const data = await c.req.json()
  return c.json(data)
})

serve(app)

c.req.json() is the slow part. The reason is well understood: inside the Node.js adapter, when json() is called the LightweightRequest path can't be used, so a real new Request() ends up being constructed.

perf: optimize request body reading

The 2.3x figure above comes from one PR specifically — PR #​301 by @​mgcrea:

The PR bundles a few changes, but the key one is "optimize request body reading". Quoting from the PR description:

The fix overrides text(), json(), arrayBuffer(), and blob() on the request prototype to read directly from the Node.js IncomingMessage using event-based I/O.

In other words, in the json() case above, we no longer convert into a Request at all — we read the body straight off the Node.js APIs. A classic fast path. That alone gives a large jump in body-parsing throughput.

The same PR also includes two other tuning improvements:

• URL construction fast-path — skip building a URL object except in edge cases
• buildOutgoingHttpHeaders optimization — skip the set-cookie header comparison when there are no cookies

v2 ships several other performance PRs as well — newHeadersFromIncoming and signal fast-paths, Response fast-paths and responseViaCache improvements, method-key caching, a regex-based buildUrl rewrite, and more (see the full list below). They all add up, but #​301 is by far the largest single contributor, which is why it gets the spotlight here.

v2 performance

Now let's measure the final v2 build.

First, comparing against the v1 Node.js adapter. dev here is v2. Body improves by 2.3x, and the other scenarios get faster too:

Next, the same comparison against other frameworks. With the Body score jumping, Hono passes Koa and Fastify and takes first place:

[!CAUTION]
Updated: The h3 entry in the earlier framework comparison was an older snapshot. Its successor srvx now ships a FastResponse mode, and in srvx's own benchmark (h3js/srvx/test/bench-node) srvx-fast (≈68,560 req/sec) beats hono-fast (≈59,477 req/sec). The methodology is different from the benchmarks above, but worth being upfront: with FastResponse enabled, srvx is faster than Hono v2 in that setup.

Breaking changes

There are two breaking changes in v2.

Dropped support for Node.js v18

Node.js v18 reached end-of-life, so v2 requires Node.js v20 or later.

Removed the Vercel adapter

The Vercel adapter (@hono/node-server/vercel) has been removed. It is no longer needed for Vercel's modern runtimes, so the recommendation is to deploy without it.

If you still need the previous behavior, the old adapter was a one-liner on top of getRequestListener and you can write the same thing in your own project:

import type { Hono } from 'hono'
import { getRequestListener } from '@​hono/node-server'

export const handle = (app: Hono) => {
  return getRequestListener(app.fetch)
}

Then use it the same way you used handle from @hono/node-server/vercel before.

All changes

A full list of what landed in PR #​316.

Performance

• perf: optimize request body reading and URL construction (#​301) by @​mgcrea
• perf: optimize buildOutgoingHttpHeaders for the common case (#​301) by @​mgcrea
• perf(request): cache method key (#​319) by @​yusukebe
• perf(url): mark host with port : as safe host (#​320) by @​yusukebe
• perf(request): optimize newHeadersFromIncoming and signal fast-path (#​332) by @​GavinMeierSonos
• perf(response, listener): Response fast-paths and responseViaCache improvements (#​333) by @​GavinMeierSonos
• perf: replace Uint8Array lookup tables with regex in buildUrl (#​345) by @​usualoma

Features

• feat: first-class support for WebSockets (#​328) by @​BlankParticle

Breaking changes

• feat: end support for Node.js v18 (#​317) by @​yusukebe
• feat!: obsolete the Vercel adapter (#​335) by @​yusukebe

Fixes & refactors

• fix: more strictly determine when new URL() should be used (#​310) by @​usualoma
• refactor: improved compatibility with the Web Standard Request object (#​311) by @​usualoma
• fix(request): return an error object instead of throwing (#​318) by @​usualoma
• refactor: improve handling of null body in response (#​341) by @​usualoma
• fix: ensure close handler is attached for Blob/ReadableStream cacheable responses (#​342) by @​usualoma
• fix: improve Response.json() and Response.redirect() spec compliance and efficiency (#​343) by @​usualoma

Build & tooling

• build: migrate from tsup to tsdown (#​302) by @​tommy-ish
• feat(test): migrate Jest to Vitest (#​303) by @​koralle
• fix: only build exported entrypoints (#​323) by @​BlankParticle
• chore: add type: module to package.json (#​336) by @​yusukebe

Wrap-up

So that's v2 of the Node.js adapter — significantly faster, with the same API. Just upgrading should give you a real performance boost. No more "Hono is slow on Node.js" excuses. Please use Hono — fast not only on Cloudflare, Bun, and Deno, but now also on Node.js.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

Superseded by a newer automated review for this pull request.

Superseded by a newer automated review for this pull request.

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — escalated (fast_request_changes,fast_low_confidence)

Review: PR PR 353 — Update @​hono/node-server (1.19.14 → 2.0.4)

Recommendation

Request changes — the upgrade introduces a breaking peer dependency change that requires resolution before merge.

---

Required Check 1: Breaking API Changes

Verified via upstream compare metadata (v1.19.14...v2.0.0):

Breaking Change	Impact on Dispatch
Node.js requirement: 18.x → 20.x	✅ Satisfied — Dispatch declares node >=24 in engines field
Package moved to ESM ("type": "module")	✅ Compatible — Next.js 16 with Node 24 handles ESM deps fine
./vercel export removed	✅ Not used by Dispatch
Export paths changed (.js → .mjs)	✅ Bundler resolves automatically
peerDependencies.hono: "^3" → "^4"	⚠️ Requires verification — see below

Critical issue: @hono/node-server@2.x now requires hono@^4 as a peer dependency. Dispatch does not list hono as a direct dependency in package.json. However, @modelcontextprotocol/sdk@^1.29.0 is a direct dependency and may pull in Hono transitively. The peer dependency constraint means npm/yarn will warn or error if the transitively resolved Hono version is <4.

Action required: Verify that the resolved Hono version (if any) satisfies ^4, or explicitly add hono@^4 to Dispatch's dependencies.

---

Required Check 2: Full Test Suite

Status: Cannot verify from corpus — No test run output is included in this PR's corpus. The PR diff only shows package.json and package-lock.json changes; no test execution artifacts (CI workflow run, local test output) are present.

Per the AGENTS.md release cut process, the full test suite (npm run test) must pass before merging. The CI workflow (.github/workflows/ci.yaml) runs tests on Node 20.x, 22.x, and 24.x.

Action required: CI must run and pass on this PR branch before merge.

---

Standards Compliance

• ✅ Dependency override follows standard npm override pattern
• ✅ Version range ^2.0.0 allows patch and minor upgrades within 2.x
• ✅ Diff is minimal (2 files, 5 additions, 5 deletions)
• ⚠️ Missing: No changelog entry or migration note for the hono peer dependency requirement

---

Evidence Provider Findings

No evidence providers were configured for this PR.

---

Tool Harness Findings

Tool harness ran successfully. Key findings:

1. package.json analysis: Confirmed node >=24 engine requirement satisfies the new @hono/node-server Node 20+ requirement.

2. No direct Hono dependency: The package.json has no hono entry in dependencies or devDependencies. This means the peer dependency on hono@^4 must be satisfied by a transitive dependency.

---

Unknowns / Needs Verification

1. Hono peer dependency resolution: Need to confirm what version of Hono is transitively resolved (likely via @modelcontextprotocol/sdk). If it's <4, the upgrade will produce a peer dependency warning or error.

2. Test suite execution: CI has not yet run on this PR. The full test suite must pass with the updated dependency.

3. Functional smoke test: Given the ESM migration and internal changes in @hono/node-server@2.x (websocket improvements, Response header handling fixes, serve-static backpressure fixes), a runtime smoke test against the Dispatch health endpoint (GET /api/health) would provide additional confidence.

---

Summary of Required Actions

Finding	Severity	Category	File	Line	Message
1	major	bug	package.json	null	peerDependencies of @hono/node-server@2.x requires hono@^4 but Dispatch has no direct Hono dependency; transitive resolution must be verified
2	minor	other	null	null	Full test suite (npm run test) must be executed and pass before merge; no test output in corpus

Verdict derived from structured findings (verdict_policy=findings_severity_gated): 0 blocker finding(s) out of 2; model verdict was 'request_changes'.