anti-slop：用这套 Oxlint 规则集，让 TypeScript 代码告别“烂代码”

代码审查时，最怕看到“这代码能跑就行”

项目里总有那么几个瞬间，让人血压飙升：一个函数里塞了十层 if，一个变量名叫 data2，或者明明有现成的工具函数，偏偏要手写一遍。等到代码审查的时候，这些“烂代码”就成了争论焦点，浪费时间不说，还容易伤感情。

有没有办法在代码提交之前，就把这些低级问题自动拦下来？今天要聊的 anti-slop 就是干这个的。

anti-slop 是什么？

anti-slop 是一个基于 Oxlint 的规则集，专门用来拒绝 TypeScript 和 JavaScript 里的“低证据”模式。所谓“低证据”，就是那些一眼看上去就不太靠谱的写法，比如：

• 明明有 Array.isArray，非得用 instanceof Array
• 字符串拼接不用模板字符串，硬用 + 号连
• 变量声明了却不用，或者重复声明
• 用 == 而不是 ===
• 等等

这套规则集是“opinionated”的，也就是说作者把自己的经验和偏好做成了规则，直接拿来用就行，不用自己再费劲配置。

实际能用来做什么？

1. 自动拦截低级错误，减少代码审查噪音

代码审查最怕的就是把时间花在“这里应该用 ===”“这个变量没用到”这种鸡毛蒜皮上。anti-slop 把这些规则都内置了，CI 里跑一遍，不合格的直接打回，审查的人就能专注在业务逻辑上。

2. 统一团队代码风格，减少争论

团队里总有人喜欢用 any，有人喜欢用 unknown；有人喜欢用 for 循环，有人非要 forEach。anti-slop 把这些争议点都定死了，大家照着规则写就行，不用天天在群里 battle。

3. 老项目渐进式改造

如果项目已经很老了，代码里一堆历史包袱，直接全量上规则可能会爆一堆错误。anti-slop 基于 Oxlint，可以按文件、按目录逐步启用，先管新代码，再慢慢清理老代码，压力小很多。

使用门槛怎么样？

上手很简单，前提是项目里已经用了 Oxlint。如果还没有，先装 Oxlint，然后加上 anti-slop 的配置就行。具体步骤：

1. 安装依赖：npm install -D oxlint anti-slop
2. 在 .oxlintrc.json 里加上：

{
  "plugins": ["anti-slop"],
  "rules": {
    "anti-slop/no-low-evidence": "error"
  }
}

3. 跑 npx oxlint 就能看到效果。

如果项目用的是 ESLint，需要先迁移到 Oxlint，或者用 Oxlint 的 ESLint 兼容模式。不过据项目介绍，Oxlint 本身速度就快，迁移成本不高。

和其他方案对比

市面上类似的规则集不少，比如 eslint-plugin-unicorn、eslint-plugin-sonarjs。anti-slop 的区别在于：

• 基于 Oxlint：速度更快，适合大项目；
• 规则更“激进”：作者只挑了自己认为最该拦的模式，不会像 unicorn 那样面面俱到；
• 配置简单：不用自己选规则，直接全开就行。

如果你已经在用 ESLint + unicorn，anti-slop 可能不是必须的；但如果你受够了 ESLint 的慢，想试试 Oxlint，anti-slop 是个不错的起点。

总结：值不值得用？

对于想提升 TypeScript 项目质量、又不想花太多时间配置规则的人来说，anti-slop 是个省心选择。它把常见的“烂代码”模式都拦住了，让代码审查更专注于业务逻辑。当然，规则集是作者主观选择的，不一定适合所有人，但作为起点，完全可以先用起来，再按需调整。

项目目前有 2k+ star，说明不少人认可这套思路。如果你也在为代码质量头疼，不妨试试看。