开发者 Ilbert 在 GitHub 上发布了名为 Bun-sqlgen 的开源项目，旨在解决 Bun 运行时下编写原生 SQL 的类型安全问题。通常在使用 Bun 的原生数据库客户端 `Bun.sql` 时，开发者面临两难选择：要么手写 SQL 获得 `any[]` 返回值导致类型缺失，要么使用 ORM 或查询构建器（如 Drizzle、Kysely）但这改变了原生 SQL 的编写习惯。Bun-sqlgen 提出了一种折中方案，允许开发者继续在迁移文件中编写原生的 Raw SQL 查询，并通过代码生成步骤来解决类型定义问题。其工作原理是：开发者在查询中添加特定名称标签，代码生成器会读取 `.sql` 迁移文件，利用 PGlite（无需 Docker）或 SQLite 启动临时的内存数据库，准备并执行这些查询，最后生成一个 `.d.ts` TypeScript 声明文件。该文件将查询名称映射到实际的结果类型，从而让 TypeScript 编译器能够检查字段是否存在及可空性。针对 PostgreSQL `describe` 接口不返回列可空性信息的限制，该项目通过查询计划和目录进行推断，并支持手动覆盖。目前该项目处于 v0.1 早期阶段，运行时完全依赖 Bun.sql，生成的类型文件可作为唯一的代码产物。
事件分析
随着前端技术栈向后端延伸（如 Bun 运行时），类型安全已成为服务端开发的核心诉求。传统的全功能 ORM 虽然提供了类型支持，但往往引入性能开销和“阻抗失配”，导致开发者难以编写优化 SQL。Bun-sqlgen 代表了“元编程”趋势：即通过代码生成器来弥合动态语言（SQL）与静态类型系统之间的鸿沟，而不是强行将 SQL 抽象成对象。利用 PGlite 进行本地化、无 Docker 的代码生成是另一大技术亮点，显著降低了开发者工具链的依赖复杂度。这种模式在 Rust（sqlx）和 Go 社区已验证过其有效性，其在 Bun 生态的出现进一步丰富了全栈类型安全的解决方案。
💡 核心观点：代码生成技术正在取代传统 ORM 抽象，在保留 SQL 灵活性的同时完美解决类型安全问题。
原文链接：Hacker News
评论前必须登录！
立即登录 注册