为什么 anti-slop 不发布 npm 依赖？“复制即拥有“ Vendoring 模式完整解析

为什么 anti-slop 不发布 npm 依赖？"复制即拥有" Vendoring 模式完整解析

【免费下载链接】anti-slopOpinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns项目地址: https://gitcode.com/gh_mirrors/ant/anti-slop

anti-slop 是一套有主见的 Oxlint 规则，专门拦截低证据、低信号的 TypeScript / JavaScript 写法。它最反直觉的一点是：作者刻意不把它发布成 npm 依赖，而是推行「复制即拥有」的Vendoring（代码内嵌）模式——把规则源码直接拷进你自己的仓库，从此它们完全归你所有。这篇文章完整解析这套设计背后的取舍。

一、anti-slop 是什么：先看这位 TypeScript 规则插件

一句话概括：anti-slop 是一个Oxlint 插件，内置15 条强主见的 lint 规则，用来拒绝那些「看起来能跑、实则缺乏证据」的类型写法。比如禁止as object as User式的链式断言、禁止用unknown敷衍函数返回、禁止把Reflect.get当万能取属性工具。

你可以从两个入口快速认识它：

• 规则总入口 src/index.ts：在这里你能一眼看到全部 15 条规则被注册成anti-slop/xxx名字。
• 清单入口 README.md：逐条列出了每条规则「拒绝什么」，新手照这张表就能看懂它管什么。

它的定位不是「大而全」，而是「有观点」。每条规则都代表一种团队编码立场，这正是后面「不发布依赖」的伏笔。

二、为什么不发布 npm 依赖？3 个关键原因

1. 直接证据：它是private包

打开 package.json 第 4 行，你会看到"private": true。在 npm 里，这个字段意味着这个包永远不会被npm publish发出去。作者从机制上就堵死了「误发依赖」的可能。

2. 官方定位：设计来被「内嵌」，而非被「依赖」

README.md 第 7 行写得很直白（原文）：

This project is meant to bevendored, not treated as a fixed npm dependency.

翻译过来就是：把它当成可内嵌的代码，而不是一个固定依赖。把源码复制进仓库、读它、按团队标准改它——这才是作者想要的用法。

3. 根本原因：有主见的规则，不该被「锁定版本」

这是最核心的一条。npm 依赖有两个隐性代价，恰好与 anti-slop 的理念冲突：

• 标准被固化：依赖里装的是「别人的团队标准」。你拿到的是别人的主见，而不是你的。
• 升级会打架：依赖一旦update，你之前对规则做的本地修改可能被覆盖，或产生版本漂移。

而 anti-slop 的规则是「有主见、且需要被本地化改造」的。把它锁成依赖，就失去了「按团队标准改它」的自由。所以它选择：把源码交到你手里，让它变成你自己的代码。

三、Vendoring（复制即拥有）模式如何运作

Vendoring（也常叫「vendor in」）是一种古老的软件复用手法：不引用一个外部库，而是把它的源码直接放进自己仓库。anti-slop 把它现代化了，核心流程只有一句话——复制 → 安装配套依赖 → 注册 → 启用。

手动安装时，做法就是「把 src/ 整目录拷到目标仓库」，例如放到tools/oxlint/anti-slop/，再装上配套版本的oxlint与@oxlint/plugins（详见 README.md）。

而更顺滑的是一键复制：在仓库里让编码 Agent 跑一条命令即可（来自 README.md）：

npx skills add dmmulroy/anti-slop --skill install-anti-slop

它会替你完成：复制插件、安装当前 Oxlint 依赖、把插件合并进现有 lint 配置、启用全部 15 条规则、最后跑一遍校验。

四、一键复制：install.mjs 如何保护你的修改

真正的复制动作由 skills/install-anti-slop/scripts/install.mjs 完成。它有两个值得新手注意的细节：

• 默认落点安全：默认复制到tools/oxlint/anti-slop/，也接受自定义目录（见 install.mjs）。
• 拒绝覆盖已有文件：如果目标目录已存在，脚本会直接拒绝（见 install.mjs）。只有在备份并审阅过之后，才允许加--force。

这条「拒绝覆盖」逻辑，恰好是「复制即拥有」的体现：一旦你改过这些文件，工具就再也不会悄悄替你覆盖掉成果。你的修改，就是你的资产。

配套的操作手册写在 skills/install-anti-slop/SKILL.md：它要求先读仓库的 Agent 说明、检查git status以保留无关改动、识别包管理器、绝不为了通过 lint 而「削弱规则或偷偷加断言」。

五、src/ 权威源：复制之后如何持续维护

有人担心：复制出去两份，将来怎么保持一致？anti-slop 用「权威源 + 一致性校验」来解这个问题。

• 权威源是 src/。开发规则只改src/，AGENTS.md 明确要求：src/才是规范的插件实现，其余都是副本。
• 同步脚本scripts/sync-skill-assets.mjs 负责把src/同步到 skill 的打包副本；它的--check模式（见 sync-skill-assets.mjs）会在 CI 里逐一比对文件，只要有一处不一致就报错。

这样就形成一个清晰的链条：src/是唯一真相 → 脚本复制到 skill 资源 → CI 校验两侧一致。你复制进仓库的那份，从此独立成长，改到哪儿、留到哪儿，都由团队说了算。

六、npm 依赖 vs Vendoring：哪种更适合你

选不选 anti-slop 的 Vendoring 路线，取决于你对「规则标准」的诉求：

• 选 Vendoring，当你想要：可定制的有主见规则、版本精确对齐、规则源码可见可读，并且团队愿意承担一点维护成本。
• 选 npm 依赖，当你想要：零维护、随上游升级、且默认标准就已满足你的需求。

对 anti-slop 这类「编码立场强烈、需要本地化」的 lint 插件而言，Vendoring 让「标准真正属于你自己团队」——这正是它宁可不上 npm 也要坚持的原因。

一句话总结：anti-slop 不发布 npm 依赖，不是偷懒，而是一种刻意的设计选择。它用「复制即拥有」的 Vendoring 模式，把有主见的 Oxlint 规则交到你手中——源码在你仓库里，标准就长在你们团队身上。

【免费下载链接】anti-slopOpinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns项目地址: https://gitcode.com/gh_mirrors/ant/anti-slop