Hono 4.13.10 lagert seine Laufzeit-Adapter in eigene Pakete aus
Victoria Shinder1 Min. LesezeitHono, das schlanke Web-Framework für verschiedene JavaScript-Laufzeiten, hat seine Laufzeit-Adapter aus dem Kernpaket herausgelöst. Laut den Versionshinweisen zu Version 4.13.10 vom 28. September sind die Adapter jetzt eigene Pakete: @hono/bun, @hono/deno, @hono/cloudflare-workers, @hono/aws-lambda, @hono/lambda-edge, @hono/netlify, @hono/vercel und @hono/service-worker. Der Deno-Adapter erscheint zusätzlich auf JSR, der JavaScript-Registry.
Für Anwendungen ändert sich ein Importpfad. Code, der eine Adapter-Hilfsfunktion aus hono/bun importiert, etwa serveStatic, holt sie nun aus @hono/bun. Die alten Pfade über hono/adapter funktionieren während der gesamten Version 4, sind aber veraltet und werden mit Version 5 entfernt. Ein Adapter bekommt keinen Nachfolger: hono/cloudflare-pages ist ohne Ersatzpaket abgekündigt, und die Hinweise verweisen auf Cloudflares Empfehlung, stattdessen Workers mit statischen Assets zu nutzen.
Der Rest der Version betrifft vor allem die Werkzeuge. Das Projekt wechselte den Paketmanager von Bun zu pnpm, ersetzte Prettier durch oxfmt und ESLint durch oxlint, aktualisierte Vitest auf 5.0.1 und führte Vite+ in den Build ein. Der Bun-Adapter wird nur noch als ESM ausgeliefert. Bei den für Nutzer sichtbaren Korrekturen erlauben die Typen nun, einen Blob als Antwortkörper zurückzugeben. Ein Folgepatch, 4.13.11, erschien am 29. September.
Was das bedeutet
Eigene Adapterpakete lassen sich unabhängig versionieren und veröffentlichen und halten laufzeitspezifischen Code aus dem Kern, den jeder Nutzer installiert. Für Anwender ist die Aufgabe klein, hat aber eine Frist: die Importpfade umstellen, solange v4 beide akzeptiert, und einen Wechsel weg vom Cloudflare-Pages-Adapter planen, der kein eigenes Paket bekommt.