为什么 anti-slop 不发布 npm 依赖复制即拥有 Vendoring 模式完整解析【免费下载链接】anti-slopOpinionated Oxlint rules for rejecting low-evidence TypeScript and JavaScript patterns项目地址: https://gitcode.com/gh_mirrors/ant/anti-slopanti-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 把它现代化了核心流程只有一句话——复制 → 安装配套依赖 → 注册 → 启用。对比维度npm 依赖Vendoringanti-slop 采用代码归属依赖包里属「上游」复制进仓库完全属你可改造成团队标准难升级易被覆盖任意改改完就是你的版本一致性可能漂移与你的 Oxlint 精确对齐可读性 / 信任需翻依赖源码源码就在仓库里随读随看维护责任上游负责你负责但也因此可控手动安装时做法就是「把 src/ 整目录拷到目标仓库」例如放到tools/oxlint/anti-slop/再装上配套版本的oxlint与oxlint/plugins详见 README.md。而更顺滑的是一键复制在仓库里让编码 Agent 跑一条命令即可来自 README.mdnpx 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么 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-slopanti-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 把它现代化了核心流程只有一句话——复制 → 安装配套依赖 → 注册 → 启用。对比维度npm 依赖Vendoringanti-slop 采用代码归属依赖包里属「上游」复制进仓库完全属你可改造成团队标准难升级易被覆盖任意改改完就是你的版本一致性可能漂移与你的 Oxlint 精确对齐可读性 / 信任需翻依赖源码源码就在仓库里随读随看维护责任上游负责你负责但也因此可控手动安装时做法就是「把 src/ 整目录拷到目标仓库」例如放到tools/oxlint/anti-slop/再装上配套版本的oxlint与oxlint/plugins详见 README.md。而更顺滑的是一键复制在仓库里让编码 Agent 跑一条命令即可来自 README.mdnpx 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考