anti-slop 是一组面向 TypeScript/JavaScript 的强约束 Oxlint 规则，目标是拒绝低证据、低信号、容易掩盖类型问题的代码模式，例如滥用 unknown、object、类型断言、Reflect、模块 mock、运行时 typeof 判断等。项目明确建议“vendored”使用：将规则源码复制到自己的仓库中，根据团队标准修改，而不是作为固定 npm 依赖长期引用。
适用领域
前端工程化 / TypeScript 代码质量 / JavaScript/TypeScript Lint / Oxlint 插件 / 静态代码分析 / AI 编码代理规范治理 / 测试规范与架构约束
配置难度
中等。对于已使用 Oxlint 的项目，初次安装和配置并不复杂；真正的难点在于理解每条规则背后的工程取舍、处理现有代码的大量违规、并根据团队场景对 vendored 规则进行裁剪和维护。
商业价值
对重视 TypeScript 类型安全、代码审查效率和 AI 生成代码质量的团队有较高价值。它可以把一些隐性的代码质量判断自动化，减少低质量类型断言和宽泛类型在代码库中扩散，长期提升可维护性和缺陷预防能力。但其商业价值依赖于团队是否愿意接受强约束规范，并投入时间进行规则定制和迁移。
01
技术亮点
- 规则目标非常明确：拒绝低证据类型模式，鼓励更可信的类型建模和边界解析。
- 覆盖了 TypeScript 项目中常见的类型安全逃逸点，例如 unknown 返回值、unknown 参数、object 参数、链式 as 断言、widen 后再 assert 等。
- 对 AI 生成代码很有针对性，可以减少 AI 为了通过编译而制造的低质量类型写法。
- 不是黑盒依赖，推荐复制到仓库后阅读、修改和维护，适合构建团队内部规范。
- 提供 agent skill，可自动完成复制、依赖安装、配置合并和验证，降低初次接入成本。
- 规则列表清晰，每条规则都有违反示例，便于团队理解其意图。
- MIT 许可证，便于商业项目复制、修改和内部使用。
02
目标用户
- 使用 TypeScript 或 JavaScript 的前端/全栈团队
- 希望提高类型安全和代码可维护性的工程团队
- 正在使用或计划使用 Oxlint 的项目
- 对 AI 生成代码质量有较高要求的团队
- 希望建立严格编码规范的技术负责人、架构师和代码审查负责人
- 愿意维护自定义 lint 规则的中高级开发者
03
配置要求
- 项目需要使用 Oxlint，并配置 oxlint.config.ts 或兼容的 Vite+ lint 配置。
- 需要安装 oxlint 和 @oxlint/plugins 的匹配当前版本。
- 需要将 anti-slop 的 src/ 规则源码复制到目标仓库中，因为作者推荐 vendored 模式，而不是长期固定 npm 依赖。
- 需要在 jsPlugins 中注册本地插件入口文件。
- 需要在 rules 中逐条启用对应规则，通常设置为 error。
- 团队需要提前评估这些规则是否符合自身编码风格，因为规则非常主观且强约束。
- 如果使用 agent skill，需要项目环境支持 npx skills，并且开发流程允许编码代理修改 lint 配置和复制文件。
04
适用场景
- 在 TypeScript 项目中禁止低质量类型逃逸模式，例如 unknown、object、any-like 字典类型和链式类型断言
- 约束 AI 编码助手生成的代码，避免其通过类型断言、宽泛类型或运行时 typeof 来绕过类型系统
- 统一团队对于类型断言、边界解析、测试 mock、字典类型等问题的编码标准
- 在代码审查前通过 Oxlint 自动发现不符合团队工程标准的代码
- 将规则复制到内部仓库后进行二次定制，形成公司或团队专属 lint 规则集
- 推动代码从临时判断和宽泛类型迁移到显式解析、明确类型建模和真实依赖 seam
05
部署与配置
- 推荐方式：使用 agent skill 安装。在目标仓库中执行：npx skills add dmmulroy/anti-slop --skill install-anti-slop
- 然后让编码代理在当前仓库中安装或配置 anti-slop。该 skill 会复制插件、安装 Oxlint 相关依赖、合并 lint 配置、启用所有规则并验证结果。
- 如需先查看可用 skill，可执行：npx skills add dmmulroy/anti-slop --list
- 手动方式：将仓库中的 src/ 复制到目标项目，例如 tools/oxlint/anti-slop/。
- 安装当前匹配版本的 oxlint 和 @oxlint/plugins。
- 在 oxlint.config.ts 中注册 jsPlugins，例如 name 使用 anti-slop，specifier 指向 ./tools/oxlint/anti-slop/index.ts。
- 在 rules 中启用 anti-slop/no-chained-type-assertions、anti-slop/no-conditional-empty-object-spread、anti-slop/no-known-value-widening、anti-slop/no-module-mocking、anti-slop/no-object-parameters、anti-slop/no-reflect-apply、anti-slop/no-reflect-get、anti-slop/no-runtime-typeof、anti-slop/no-shape-in-symbol-names、anti-slop/no-unknown-parameters、anti-slop/no-unknown-returns、anti-slop/no-unknown-type-aliases、anti-slop/no-unsafe-dictionary-type、anti-slop/no-widen-then-assert、anti-slop/require-safety-comment-for-type-assertion 等规则。
- 开发或修改规则时，在本仓库运行 pnpm install 和 pnpm check；修改生产源码后运行 pnpm sync:skill-assets 保持 skill 资产同步。
06
风险与注意事项
- 规则非常 opinionated，可能与很多团队的现有 TypeScript 实践冲突，接入后可能产生大量 lint 报错。
- 禁止 runtime typeof、module mocking、unknown 参数等规则可能过于激进，在处理外部输入、测试隔离、库开发等场景中需要谨慎调整。
- 项目建议 vendored 使用，意味着后续规则升级、bug 修复和内部维护需要团队自己承担。
- 如果团队没有统一的边界解析、依赖注入、测试 seam 等工程实践，直接启用所有规则可能会显著增加开发阻力。
- Oxlint 插件生态相对 ESLint 更年轻，团队需要确认与现有 CI、IDE、Monorepo、构建工具链的兼容性。
- 规则名称和理念带有强主观性，不适合作为未经讨论的公司级硬性规范直接落地。
- 星标数较高但 fork 数较少，说明关注度不错，但实际二次开发和社区贡献规模仍有限。
2026-08-15
第19名
新收录 · github_search
2026-08-14
第15名
新收录 · github_search
