Плагин Cursor для Hono v4 (TypeScript edge веб-фреймворк). 59 LLM-регрессий с парами BAD/CORRECT. Привязан к hono ^4.12.19 (>= 4.9.7 для CVE-2025-59139). Охватывает утечки middleware Express, удаленные API из v3, ловушки вывода RPC, особенности Cloudflare Workers, стандарты безопасности, усиление JSX SSR.
roninforge/roninforge-hono
Плагин для Cursor для Hono v4 (фреймворк для edge-приложений на TypeScript) + TypeScript. Привязан к hono ^4.12.19, @hono/zod-validator ^0.8.0, @hono/zod-openapi ^1.4.0 (peer zod ^4.x), @hono/node-server ^2.0.3 (Node 20+). Обучает API v4, которые LLM, обученные на данных до 2024 года, не знают (c.json() всегда типизирован, валидатор выбрасывает HTTPException, getCookie/setCookie из hono/cookie, c.env как свойство, streamText из hono/streaming, showRoutes из hono/dev, getRuntimeKey из hono/adapter, fire(app) из hono/service-worker, привязка Workers Static Assets вместо устаревшего serveStatic, JSR @hono/hono для Deno). Выявляет 50+ регрессий LLM с парами ПЛОХО / ПРАВИЛЬНО TypeScript.
Hono v5 не существует. Последняя стабильная версия — v4.12.19. Любая "v5" в сгенерированном коде — галлюцинация.
Сами разработчики Hono создали Issue #3906 ("файл llm.txt") и Issue #4812 ("Официальный навык AI-агента для Hono") явно потому, что "LLM практически не имеют знаний о том, как работает последний Hono." Данные для обучения до 2025 года относятся к эпохе v3. LLM выдают:
c.jsonT() вместо c.json() (всегда типизирован начиная с v4.0.0)c.stream() / c.streamText() как методы Context (перенесены в hono/streaming в v4)c.env() в виде функции (теперь свойство; определение среды выполнения через getRuntimeKey() из hono/adapter)c.req.cookie() (удалено; используйте getCookie(c) из hono/cookie)app.showRoutes(), app.routerName (перенесено в hono/dev)addEventListener('fetch') + app.handleEvent() (синтаксис Service Worker; используйте export default { fetch: app.fetch })app.head(...) маршруты (HEAD автоматически выводится из GET в v4)hono/nextjs импорт (используйте hono/vercel)hono/middleware баррель-импорт (используйте отдельный подпуть для каждого middleware)c.req.headers() / c.req.body() / c.req.signal() методы доступа (используйте c.req.raw.*)FC с неявными children (используйте PropsWithChildren<P>)app.fire() (устарело с v4.8.0; используйте fire(app) из hono/service-worker)import { Hono } from 'https://deno.land/x/hono/mod.ts' на Deno (устарело с v4.4.0; используйте jsr:@hono/hono)return в c.json() (возвращает undefined; v4 выдает "Context is not finalized")res.json() / res.send() вместо c.json() (в Hono нет res)(req, res, next) сигнатура middleware (используйте (c, next))(err, req, res, next) middleware для ошибок (используйте app.onError + HTTPException)app.use(express.json()) парсер тела (Hono парсит по требованию через c.req.json())import cors from 'cors' из npm (используйте hono/cors)supertest для тестов (используйте app.request() / testClient(app))c.req.body как уже распарсенный (это ReadableStream)c.req.parseBody() для JSON (только form / multipart)c.req.text() затем c.req.json() (тело потребляется дважды)c.userId = ... прямое присваивание (используйте c.set('userId', ...) с типизированными Variables)new Hono() без обобщений Bindings / Variables (c.env — {})app.get(...) затем app.post(...)) — теряют типы RPCapp.route() как операторы — то же правилоContext (теряют вывод параметров пути, по Hono Best Practices)app.use('/path', zValidator(...)) вместо аргумента маршрута (ошибка TS: 'json' not assignable to 'never')c.notFound() в маршрутах, потребляемых RPC (нельзя типизировать на клиенте)new Response(JSON.stringify(...)) в маршрутах RPC (клиент видит unknown)hc<AppType>('/') относительный URL (выбрасывает ошибку при $url())drizzle-orm, fs, нативные зависимости – главная ловушка раздувания бандла RPC)createMiddleware<Env> (типы Variables не распространяются)process.env.X в коде Workers (undefined; используйте c.env.X с типизированными Bindings)fs / path в Workers (нет файловой системы)compatibility_flags: ["node_compat"] (используйте nodejs_compat)serveStatic из hono/cloudflare-workers (начиная с v4.3.0; используйте привязку assets)c.executionCtx.waitUntil() для fire-and-forgetif (c.executionCtx) (геттер выбрасывает исключение на Bun и Next.js App Router).run() / .first() / .all() (вставка отменяется при завершении worker)secureHeaders()csrf() на cookie-аутентифицированных мутацияхcors({ origin: '*', credentials: true }) (браузеры молча отбрасывают; AJAX падает)bodyLimit() на POST / PUT маршрутах и фиксация hono >= 4.9.7 для CVE-2025-59139httpOnly / secure / sameSite / pathsameSite: 'None' без secure: true (молча отбрасывается)etag() / cache() на статических GETstreamText (лимит Workers 128MB)notFound для подприложения (мёртвый код; срабатывает только верхнего уровня)/users и /users/ — разные маршруты по умолчанию)await next() более одного раза (удваивает работу нижестоящих)app.use(prefix, mw) + app.route(prefix, subApp) (middleware срабатывает дважды)app.basePath('/api') как оператор (префикс теряется из типа)serve(app) на @hono/node-server (используйте serve({ fetch: app.fetch }))export default app на Workers (используйте export default { fetch: app.fetch })Bun.serve({ fetch: app }) (используйте app.fetch)c.req.query() без аргумента, когда ожидается одно значениеc.req.param('id') в глобальном middleware (undefined, где :id нет в пути)@hono/zod-openapicors() подключён ПОСЛЕ маршрутов (никогда не совпадает)Несколько правил Hono уже существуют на cursor.directory и в awesome-cursorrules (PR #152): они покрывают возврат c.json(), zValidator + Zod, c.env для Workers, цепочки маршрутов для RPC и экспорт Workers app.fetch. У них есть три структурных проблемы, которые исправляет этот плагин: