colinhacks/reylo
把 .sql 文件直接导入 TypeScript 并获得完整类型推断,类型来自开发数据库而非代码生成。
解决什么问题
在 TypeScript 项目里写 SQL,类型往往靠第二处维护:手写行类型、跑 codegen 生成 .d.ts、或者换成查询构建器。只要类型和 SQL 分开,就可能过期,直到测试或线上报错才被发现。Reylo 让 .sql 文件可以直接 import,SQL 文本本身成为唯一事实来源,类型由类型检查器在需要时向 Reylo 索取。
有什么不同
常见做法是 codegen:watcher 或 CLI 读 schema 并写出类型文件,你只能相信它是最新的。Reylo 走的是 TypeScript 新推出的 content mappers,tsc 在编译时直接问 Reylo 类型;Reylo 让开发数据库 prepare 这条查询但不执行,读回列和参数的类型,再叠加可空性、基数(唯一键匹配是 Row | null,聚合是 Row)、枚举联合和 JSON 形状。相比 Kysely 这类查询构建器或 Prisma 的 raw SQL 逃生口,你保留任意 SQL、函数和方言,类型跟着 SQL 文本走。代价是类型检查依赖一个可连上的数据库和一个实验性的编译器特性。
适合谁
适合已经在手写 SQL、使用 pg、postgres.js、mysql2、better-sqlite3、D1 等原生驱动,又想要编辑器级类型检查但不想引入 ORM 的团队。也适合 Agent 参与的开发流程,因为不存在需要记得重新生成的派生文件。如果你还在旧版 TypeScript、类型检查时无法启动数据库、或者需要今天就能长期支持的工具链,就不适合。
上手成本
README 写得很明确:需要 TypeScript 7.1 beta、Node 24+、一个正在运行的开发数据库作为 DATABASE_URL,并且要用 tsc --runExternalCode。还要在 tsconfig.json 里配置 contentMappers,运行时再加插件(或 --import reylo/register)让 import 能解析。对一个年轻项目来说环节不少,锁定 beta 编译器是实打实的风险。MIT 协议;README 在配置上讲得细,但对失败模式和长期维护说得很少。
点评
HotRepo 数据显示这是一个只有 3 天的仓库,1,207 stars,日均约 316,没有 Hacker News 讨论,也没有上过趋势榜。这是爆发式增长,不是成熟项目。思路确实有意思,作者在 TypeScript 社区也有名气,但卖点建立在一个 beta 编译器特性和必须连库的前提上。可以在副项目里试用,在 TypeScript 7.1 正式发布、项目积累出履历之前,不要放到关键路径上。
本文由 AI 根据项目 README 生成,更新于 2026年10月24日,以项目官方文档为准。