declint：用 YAML 自定义代码检查规则的轻量工具

代码检查（lint）工具几乎是现代开发流程的标配，但主流 linter 往往只覆盖通用规则，团队内部那些"心照不宣"的编码约定却很难落地。一款名为 declint 的新工具试图填补这个空白——它让开发者用 YAML 直接编写自定义 lint 规则，把团队的"家规"变成可自动执行的检查项。

用 YAML 定义你自己的检查规则

declint 的核心理念很直接：规则本质上就是一段正则 + 一条提示信息。举个常见的例子，如果你想在同事写出 except Exception: pass 这种"吞掉异常"的代码时得到警告，只需要写几行 YAML 配置：

version: 1
rules:
  - id: except-pass
    pattern: 'except Exception:\n *pass'
    severity: warning
    message: 'swallowed exception'

这种声明式的写法门槛极低。对比传统 linter 需要编写插件、理解 AST、发布包的繁琐流程，declint 把自定义规则的成本压缩到了几乎只需要会写正则的程度。对于那些"stock linters 永远不会内置"的团队专属约定来说，这正是它的价值所在。

正则不够用时，还能写 Lua

纯正则虽然覆盖了大量场景，但面对需要上下文判断或更复杂逻辑的检查时就会力不从心。declint 的应对方案是引入 Lua 脚本：当一条规则无法用正则表达时，可以切换到 Lua 编写更复杂的判断逻辑。

这种"简单场景用 YAML，复杂场景用脚本"的分层设计是比较务实的。它既保留了声明式配置的易用性，又在必要时提供了编程语言级别的灵活度，避免了工具能力天花板过低的问题。

Lua 在此类工具中被选用并非偶然。作为一门轻量级嵌入式脚本语言，Lua 的运行时体积极小（通常只有几百 KB），非常适合嵌入到以性能著称的 Rust 程序中，同时提供完整的编程能力。与 JavaScript（如 ESLint 插件）或 Python 相比，Lua 的启动开销几乎可以忽略不计，不会显著拖慢 CI 流水线的执行速度。对于规则编写者来说，Lua 语法简洁，学习曲线平缓，能够处理字符串匹配、多行上下文分析、计数判断等正则难以胜任的场景，例如"同一函数中 TODO 注释超过三条则报警"或"import 语句必须按字母序排列"这类需要状态跟踪的逻辑。

覆盖 CI 与编辑器的完整链路

一款检查工具真正好用的关键，在于它能否无缝嵌入日常开发流程。declint 在这方面做了两端覆盖：

• CI 集成：规则可以在持续集成流水线中运行，并通过 --format github 输出内联的 PR 注释（inline PR annotations），直接把问题标注在代码评审界面上。
• 编辑器集成：通过 LSP（语言服务器协议）接入编辑器，目前已提供 Neovim 插件 declint.nvim，让检查在编码过程中实时反馈。

从本地编辑器到 PR 评审的闭环，意味着规则不只是事后的"门禁"，更能在开发早期就给出提示，降低返工成本。

LSP（Language Server Protocol，语言服务器协议）是由微软主导、于 2016 年随 VS Code 推出的开放标准，旨在将编辑器功能（补全、跳转、诊断）与语言分析逻辑解耦。通过统一协议，一个语言服务器可以同时服务于支持 LSP 的任意编辑器，避免每种编辑器都需要单独开发插件的重复工作。declint 借助 LSP 接入编辑器，意味着理论上所有兼容 LSP 的编辑器（VS Code、Helix、Emacs、Zed 等）都可以复用同一套检查逻辑，目前优先提供 Neovim 插件只是生态建设的起点。对于开发者而言，LSP 集成带来的最直接体验是：违规代码在输入时立即出现波浪线提示，而无需等到提交或 CI 阶段才发现问题。

规则可测试、可共享

declint 还考虑到了规则本身的可维护性。每条规则都可以携带内嵌的测试用例（embedded fixtures），通过 declint test 命令直接运行验证。这意味着规则不再是"写完就不管"的黑盒，而是像代码一样可以被测试、被信任。

在分发层面，declint 内置了多种语言和格式的预设（preset），涵盖 Python、INI、Markdown、shell、Dockerfile、TOML、JSON、JS。此外还支持社区规则集（community rulesets），开发者可以用一行命令拉取现成的规则库，不必从零开始积累。

安装与定位

declint 基于 Rust 构建，安装方式为 cargo install declint。作者目前在 Reddit 上发布了该项目并征集反馈，整体仍处于早期推广阶段。

从定位上看，declint 并不打算取代 ESLint、Pylint 这类成熟的语言专属 linter，而是作为补充——专门解决"通用 linter 管不到的团队自定义约定"这一痛点。它的跨语言、跨格式特性，加上低门槛的 YAML 配置，让它在多语言仓库或需要统一编码规范的团队中可能特别有用。

对于那些长期靠 code review 口头提醒、或者维护着一堆零散脚本做自定义检查的团队，declint 提供了一个值得尝试的统一方案。当然，作为新工具，其社区规则生态的丰富程度和长期维护情况，还需要时间来验证。