hono

What version of Hono are you using? 4.13.18 What runtime/platform is your app running on? (with version if possible) Node.js 26.13.0, TypeScript 7.0.2, @hono/node-server 2.1.7 What steps can reproduce the bug? A Node project with and no lib: What is the expected behavior? The declarations type-check without the DOM lib. What do you see instead? Additional information uses two globals that exist only in : the generic on lines 16 and 95, and on line 82. Without the DOM lib, declares a non-generic global in and no at all, so the first two become TS2315 and the third TS2304. Importing on its own is clean. drags the file in because its type entry imports from , so a Node app hits this whether or not it uses WebSockets. Adding to clears the errors but puts browser globals into a server program. #4768 removed the same dependency from and for this exact reason. The WebSocket helper was left out of it. A fix in the same shape: declare locally as , which is the DOM definition, and give the helper its own message event type instead of the DOM generic. Only the declarations change; can keep constructing a runtime . I can send a PR if you want one.

What version of Hono are you using? 4.13.18 What runtime/platform is your app running on? (with version if possible) node 26.12.1 What steps can reproduce the bug? What is the expected behavior? Expecting either 1. no regression in a patch release, or 2. explicit documentation so this is easier to diagnose (as it may be a security-related patch, so maybe the regression was deemed worth it). The new behaviour looks intentional. b982c029 says it slices the matched prefix "including after route grouping", adds a test to , and fixes nested mounts on a sub-path which used to forward a garbled path: So 4.13.18 is consistent: the whole routed prefix gets stripped. But inside used to forward the full path, and that worked the same way across many versions. Apps that mount a non-Hono handler this way, expecting it to see the full URL, change behavior in a patch release. What do you see instead? The mounted handler receives the path with the outer prefix removed ( instead of ). Additional information _No response_

What version of Hono are you using? 4.13.18 (same result on 4.13.7 and on at f6fbaf0) What runtime/platform is your app running on? (with version if possible) on Node.js 22.22.2 with happy-dom 21.0.4. jsdom 31.0.0 gives the same output. I haven't tried a browser. What steps can reproduce the bug? Render an whose child throws, so the fallback shows. Then re-render the component that renders the boundary, for example by setting its state. The child still throws. The script below does this for one boundary, then for a list with one boundary per row: it removes the first row, then reorders the rest. Each case also runs with nothing throwing, as a control. What is the expected behavior? Each step should look like a first render of the same state: one fallback element where the child throws, everything else updated, and no errors. What do you see instead? One boundary: each parent update rejects with . The parent's own change (, ) never reaches the DOM. After the second update the fallback is in the DOM twice. Unkeyed list: no error, but the DOM is wrong. After is removed, is still there (). After the reorder to there are four rows. Keyed list: the same TypeError on both updates. After the reorder the fallback is there twice and comes last. Controls: with nothing throwing, every update is correct. The TypeErrors are unhandled rejections from . This is the first one from (f6fbaf0), run from source, with paths shortened: Additional information I traced the one-boundary and keyed-list cases on (f6fbaf0), with temporary logging in : 1. When the parent re-renders, rebuilds the boundary, and its child throws again. 2. The block builds the fallback into the boundary (L699). The check for applying it right away now passes: , which always holds for 's handler, and is set. So it applies the boundary and returns (L700-L707) instead of throwing (L709). 3. The outer call for the same boundary is still on the stack. It carries on, and at L659-L660 it sets the boundary's back to the children that threw and moves the fallback into . 4. When the parent is applied, walks into the child that threw. That node has no , so L310 throws. In the unkeyed list, the row that throws reuses the node of the row that was there before (). That node still has its old , so nothing throws, and shows up next to the fallback. The first render is correct because isn't set yet. So is thrown, and the boundary's own returns before L659-L660. This change fixes every case in the script, with no errors. It skips the immediate apply while the boundary is still being built in the same pass: Tests: I ran the tests with vitest 5.0.1, jsdom 22.1.0 and the three project settings from . I used plain vitest, not . They give 2182 passed and 9 skipped, with and without the change. One more behavior change: take a child that rendered fine, then threw during its own state update. On a later parent re-render it throws again. On the DOM then goes back to the child's last good output (). With the change, the fallback stays (). Not checked:** other paths through that branch, so it may not be the right fix. Taking from , with and the hooks still from , gives the same output.