基于 typos-cli 的代码库拼写检查与维护实战Vitest 仓库 Typo Checker 技能全解【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest本文围绕 Vitest 仓库中内置的 .claude/skills/typo-checker/SKILL.md 技能文档系统讲解如何用typos-cli对代码库做例行拼写维护从扫描、分类、修复到维护_typos.toml配置的完整闭环。读完本文你将掌握一套可直接复制到任何 TypeScript / JavaScript 仓库的拼写质量保障流程并能借助 Vitest 仓库真实的_typos.toml配置理解「真实拼写错误」与「误报豁免」的取舍原则。技能定位为什么代码库需要拼写检查Typo Checker 是 Vitest 仓库为 AI AgentClaude Code 等内置的一项开发技能其frontmatter中明确声明了触发场景例行代码库卫生维护、用户提及拼写或拼写检查、以及定时维护任务。它的核心工作流只有一句话用typos-cli扫描代码库审查发现项修复真实拼写错误并通过更新_typos.toml配置抑制误报。拼写错误在大型开源仓库中是一种隐蔽的技术债错误的变量名被多处引用后难以统一重命名测试名拼错会导致报告难以检索文档与 JSDoc 中的错别字会降低开发者与 LLM 阅读源码的效率。而自动化工具的价值在于——它不会漏看一个被埋在深层的recieve或seperate。Vitest 仓库在根目录维护了一份真实的 _typos.toml它既是误报豁免清单也是「哪些词被判定为可接受」的活文档本文后续将结合它逐一展开。环境准备安装 typos-clitypos-cli是一个用 Rust 编写的拼写检查工具扫描速度快、输出格式稳定、天然支持.gitignore规则。SKILL.md 给出了四种安装方式方法命令cargocargo install typos-clibrewbrew install typos-clipipxpipx install typosBinary从 typos 官方 GitHub Releases 下载预编译二进制前三种分别面向 Rust 开发者、macOS 用户与 Python 环境第四种适用于任何平台直接下载对应架构的可执行文件放入PATH即可。安装完成后可用typos --version验证。工作流第一步扫描代码库基础扫描命令typos --formatbrief这是技能的默认扫描方式输出格式为每行一个发现项file:line:col: typo - suggestion例如src/utils/helpers.ts:42:7:seperate-separate。brief格式紧凑、易于机器解析既适合人眼快速浏览也适合交给sed、grep等管道命令做二次加工。一个重要的默认行为typos默认尊重.gitignore因此node_modules/、dist/、各类构建产物天然被排除在外无需额外配置。这保证了扫描结果聚焦于真正的源码、文档与配置文件。先看全局按频率统计发现项在动手修复前先获得整体视图SKILL.md 提供了一个管道命令# Count unique typo words by frequency typos --formatbrief 21 | sed s/.*\//;s/\.*// | sort | uniq -c | sort -rn | head -20其工作原理是先用sed从每行输出中抽取反引号内的建议词即-右侧的修正建议再排序、去重、计数最终按出现次数降序展示前 20 个高频错误词。这能帮你快速识别两类情况系统性错误某个词在几十个文件中都拼错了说明可能源于早期的复制粘贴值得统一批量修复来源集中的误报如果大量发现项来自压缩产物minified files或生成文件SKILL.md 建议先不要逐条处理而是把这些路径加入_typos.toml的extend-exclude然后重新扫描让后续结果更干净。工作流第二步对每个发现项分类扫描完成后对每一个发现项只有两种裁决真实拼写错误Real typo——修复它误报False positive——加入_typos.toml豁免。SKILL.md 归纳了常见的误报模式结合 Vitest 仓库真实的 _typos.toml我们可以得到一一对应的实例误报模式说明Vitest_typos.toml中的实例恰好是单词的短变量名单字母/双字母变量ba、fo、ndba bab-a 注解差异变量前缀、nd nd序数后缀、fo fo测试数据字符串领域缩写如alsAsyncLocalStorage 缩写、PnPYarn PlugnPlayals als、Pn Pn、PnP PnP正则/文件扩展名.styl、.pcss等样式扩展名styl stylStylus CSS 预处理器扩展名测试夹具字符串与测试数据fixture 中刻意构造的字符串som som带反引号转义的测试字符串som\e内联快照的行截断残留快照被截断产生的afte...、wrapp...afte afte、wrapp wrapp测试输出中的行截断残留产品名与专有名词品牌、项目名Evalite Evaliteevalite.dev 产品名Lorem ipsum 文本占位假文中的拉丁词optio optio此外Vitest 的_typos.toml中还有一个非常有意思的条目# Typo in upstream tinyhighlight LICENSE (TODO: fix upstream) Additionaly Additionaly它说明Additionaly是上游tinyhighlight项目 LICENSE 中真实存在的拼写错误但因为是第三方上游文件Vitest 选择先豁免并在注释中留下TODO: fix upstream等待上游修复后再移除豁免。这是一个「明知是真错但暂不处理」的经典案例体现了豁免清单注释的重要性——没有注释后续维护者无法区分「故意豁免」与「误加豁免」。分类时还需注意一条硬性原则SKILL.md 原文强调当你不确定一个拼错的变量名是否「有意为之」时——它仍然是拼写错误。传播开的错误仍然是错误请修复它们。即「意图存疑时按真错处理」避免因为偷懒而把错误扩散成规范。工作流第三步修复真实拼写错误分类为真实错误的发现项按下述四类分别处理注释、文档、JSDoc直接修正文本内容风险最低变量/属性名需要一致性重命名所有出现位置——先全局搜索该标识符的所有引用逐一改名确保编译与测试不破测试名修正测试名称后必须同步更新对应的快照snapshot文件否则toMatchSnapshot等断言会因名称变更而失败文件名重命名文件并更新所有 import / 引用——重命名前务必先搜索引用点确认没有遗漏的导入路径。第四类风险最高因为它牵涉模块解析。Vitest 这类同时存在 ESM 与 CJS 构建、且包名到目录映射复杂的仓库重命名文件前用rg old-name全库搜索引用是最低要求。工作流第四步维护_typos.toml配置误报的处理不是简单地在代码里加豁免而是统一收敛到_typos.toml保证「一次豁免永不复发」。单词级豁免[default.extend-words]每个条目必须附带解释原因的注释[default.extend-words] # AsyncLocalStorage abbreviation als als语法为错误词 正确写法实际上写回原文即可typos将其视为合法词表。SKILL.md 明确要求注释解释为什么豁免这在后续代码审查中是决策依据。文件级排除[files].extend-exclude当整类文件不该被扫描时使用 glob 排除[files] extend-exclude [ *.js.map, *.svg, ]Vitest 仓库实际的 _typos.toml 中文件级排除正是这样配置的还额外排除了test/e2e/test/fixtures/reporters/html/**e2e 测试中生成的 HTML 报告夹具目录[files] extend-exclude [ *.js.map, *.svg, test/e2e/test/fixtures/reporters/html/**, ]如果仓库还不存在_typos.toml直接创建它即可——该文件通常位于仓库根目录与.gitignore平级。工作流第五步统一提交修复与配置更新应作为一个整体提交SKILL.md 给出的提交信息格式为chore: fix typos and update _typos.toml这样做的收益是提交历史可追溯审查者看到_typos.toml的变更时能在同一个 commit 里找到对应的修复内容与豁免理由。如何把 Typo Checker 接入例行维护回到技能文档 frontmatter 中对触发时机的定义这套流程适合三种接入方式周期性卫生维护如每个迭代周期或版本发布前跑一次typos --formatbrief避免拼写错误随功能开发累积用户主动触发当用户提到 typos / 拼写检查时直接执行定时任务scheduled task在 CI 或 Agent 定时任务中编排作为代码质量门禁的一环。在 Vitest 仓库的实践中整个流程可以浓缩为五步操作扫描 → 分类 → 修复 → 更新_typos.toml→ 提交。其中_typos.toml是这个闭环的「记忆」——每次豁免都沉淀为带注释的配置项让误报处理从一次性劳动变成可持续维护的资产。小结拼写检查看起来是小事但在 Vitest 这样拥有packages/、docs/、test/数百个文件、且文档会被搜索引擎与 LLM 反复检索的开源仓库中拼写质量直接影响代码可读性与文档可信度。Typo Checker 技能的精髓在于一套可审计的取舍流程用typos-cli保证扫描的全面性用_typos.toml的带注释豁免保证误报处理的透明性用「意图存疑即按真错」的原则保证修复的彻底性。参考 .claude/skills/typo-checker/SKILL.md 与 _typos.toml你可以在自己的仓库中复刻这一整套维护实践。【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
基于 typos-cli 的代码库拼写检查与维护实战：Vitest 仓库 Typo Checker 技能全解
基于 typos-cli 的代码库拼写检查与维护实战Vitest 仓库 Typo Checker 技能全解【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest本文围绕 Vitest 仓库中内置的 .claude/skills/typo-checker/SKILL.md 技能文档系统讲解如何用typos-cli对代码库做例行拼写维护从扫描、分类、修复到维护_typos.toml配置的完整闭环。读完本文你将掌握一套可直接复制到任何 TypeScript / JavaScript 仓库的拼写质量保障流程并能借助 Vitest 仓库真实的_typos.toml配置理解「真实拼写错误」与「误报豁免」的取舍原则。技能定位为什么代码库需要拼写检查Typo Checker 是 Vitest 仓库为 AI AgentClaude Code 等内置的一项开发技能其frontmatter中明确声明了触发场景例行代码库卫生维护、用户提及拼写或拼写检查、以及定时维护任务。它的核心工作流只有一句话用typos-cli扫描代码库审查发现项修复真实拼写错误并通过更新_typos.toml配置抑制误报。拼写错误在大型开源仓库中是一种隐蔽的技术债错误的变量名被多处引用后难以统一重命名测试名拼错会导致报告难以检索文档与 JSDoc 中的错别字会降低开发者与 LLM 阅读源码的效率。而自动化工具的价值在于——它不会漏看一个被埋在深层的recieve或seperate。Vitest 仓库在根目录维护了一份真实的 _typos.toml它既是误报豁免清单也是「哪些词被判定为可接受」的活文档本文后续将结合它逐一展开。环境准备安装 typos-clitypos-cli是一个用 Rust 编写的拼写检查工具扫描速度快、输出格式稳定、天然支持.gitignore规则。SKILL.md 给出了四种安装方式方法命令cargocargo install typos-clibrewbrew install typos-clipipxpipx install typosBinary从 typos 官方 GitHub Releases 下载预编译二进制前三种分别面向 Rust 开发者、macOS 用户与 Python 环境第四种适用于任何平台直接下载对应架构的可执行文件放入PATH即可。安装完成后可用typos --version验证。工作流第一步扫描代码库基础扫描命令typos --formatbrief这是技能的默认扫描方式输出格式为每行一个发现项file:line:col: typo - suggestion例如src/utils/helpers.ts:42:7:seperate-separate。brief格式紧凑、易于机器解析既适合人眼快速浏览也适合交给sed、grep等管道命令做二次加工。一个重要的默认行为typos默认尊重.gitignore因此node_modules/、dist/、各类构建产物天然被排除在外无需额外配置。这保证了扫描结果聚焦于真正的源码、文档与配置文件。先看全局按频率统计发现项在动手修复前先获得整体视图SKILL.md 提供了一个管道命令# Count unique typo words by frequency typos --formatbrief 21 | sed s/.*\//;s/\.*// | sort | uniq -c | sort -rn | head -20其工作原理是先用sed从每行输出中抽取反引号内的建议词即-右侧的修正建议再排序、去重、计数最终按出现次数降序展示前 20 个高频错误词。这能帮你快速识别两类情况系统性错误某个词在几十个文件中都拼错了说明可能源于早期的复制粘贴值得统一批量修复来源集中的误报如果大量发现项来自压缩产物minified files或生成文件SKILL.md 建议先不要逐条处理而是把这些路径加入_typos.toml的extend-exclude然后重新扫描让后续结果更干净。工作流第二步对每个发现项分类扫描完成后对每一个发现项只有两种裁决真实拼写错误Real typo——修复它误报False positive——加入_typos.toml豁免。SKILL.md 归纳了常见的误报模式结合 Vitest 仓库真实的 _typos.toml我们可以得到一一对应的实例误报模式说明Vitest_typos.toml中的实例恰好是单词的短变量名单字母/双字母变量ba、fo、ndba bab-a 注解差异变量前缀、nd nd序数后缀、fo fo测试数据字符串领域缩写如alsAsyncLocalStorage 缩写、PnPYarn PlugnPlayals als、Pn Pn、PnP PnP正则/文件扩展名.styl、.pcss等样式扩展名styl stylStylus CSS 预处理器扩展名测试夹具字符串与测试数据fixture 中刻意构造的字符串som som带反引号转义的测试字符串som\e内联快照的行截断残留快照被截断产生的afte...、wrapp...afte afte、wrapp wrapp测试输出中的行截断残留产品名与专有名词品牌、项目名Evalite Evaliteevalite.dev 产品名Lorem ipsum 文本占位假文中的拉丁词optio optio此外Vitest 的_typos.toml中还有一个非常有意思的条目# Typo in upstream tinyhighlight LICENSE (TODO: fix upstream) Additionaly Additionaly它说明Additionaly是上游tinyhighlight项目 LICENSE 中真实存在的拼写错误但因为是第三方上游文件Vitest 选择先豁免并在注释中留下TODO: fix upstream等待上游修复后再移除豁免。这是一个「明知是真错但暂不处理」的经典案例体现了豁免清单注释的重要性——没有注释后续维护者无法区分「故意豁免」与「误加豁免」。分类时还需注意一条硬性原则SKILL.md 原文强调当你不确定一个拼错的变量名是否「有意为之」时——它仍然是拼写错误。传播开的错误仍然是错误请修复它们。即「意图存疑时按真错处理」避免因为偷懒而把错误扩散成规范。工作流第三步修复真实拼写错误分类为真实错误的发现项按下述四类分别处理注释、文档、JSDoc直接修正文本内容风险最低变量/属性名需要一致性重命名所有出现位置——先全局搜索该标识符的所有引用逐一改名确保编译与测试不破测试名修正测试名称后必须同步更新对应的快照snapshot文件否则toMatchSnapshot等断言会因名称变更而失败文件名重命名文件并更新所有 import / 引用——重命名前务必先搜索引用点确认没有遗漏的导入路径。第四类风险最高因为它牵涉模块解析。Vitest 这类同时存在 ESM 与 CJS 构建、且包名到目录映射复杂的仓库重命名文件前用rg old-name全库搜索引用是最低要求。工作流第四步维护_typos.toml配置误报的处理不是简单地在代码里加豁免而是统一收敛到_typos.toml保证「一次豁免永不复发」。单词级豁免[default.extend-words]每个条目必须附带解释原因的注释[default.extend-words] # AsyncLocalStorage abbreviation als als语法为错误词 正确写法实际上写回原文即可typos将其视为合法词表。SKILL.md 明确要求注释解释为什么豁免这在后续代码审查中是决策依据。文件级排除[files].extend-exclude当整类文件不该被扫描时使用 glob 排除[files] extend-exclude [ *.js.map, *.svg, ]Vitest 仓库实际的 _typos.toml 中文件级排除正是这样配置的还额外排除了test/e2e/test/fixtures/reporters/html/**e2e 测试中生成的 HTML 报告夹具目录[files] extend-exclude [ *.js.map, *.svg, test/e2e/test/fixtures/reporters/html/**, ]如果仓库还不存在_typos.toml直接创建它即可——该文件通常位于仓库根目录与.gitignore平级。工作流第五步统一提交修复与配置更新应作为一个整体提交SKILL.md 给出的提交信息格式为chore: fix typos and update _typos.toml这样做的收益是提交历史可追溯审查者看到_typos.toml的变更时能在同一个 commit 里找到对应的修复内容与豁免理由。如何把 Typo Checker 接入例行维护回到技能文档 frontmatter 中对触发时机的定义这套流程适合三种接入方式周期性卫生维护如每个迭代周期或版本发布前跑一次typos --formatbrief避免拼写错误随功能开发累积用户主动触发当用户提到 typos / 拼写检查时直接执行定时任务scheduled task在 CI 或 Agent 定时任务中编排作为代码质量门禁的一环。在 Vitest 仓库的实践中整个流程可以浓缩为五步操作扫描 → 分类 → 修复 → 更新_typos.toml→ 提交。其中_typos.toml是这个闭环的「记忆」——每次豁免都沉淀为带注释的配置项让误报处理从一次性劳动变成可持续维护的资产。小结拼写检查看起来是小事但在 Vitest 这样拥有packages/、docs/、test/数百个文件、且文档会被搜索引擎与 LLM 反复检索的开源仓库中拼写质量直接影响代码可读性与文档可信度。Typo Checker 技能的精髓在于一套可审计的取舍流程用typos-cli保证扫描的全面性用_typos.toml的带注释豁免保证误报处理的透明性用「意图存疑即按真错」的原则保证修复的彻底性。参考 .claude/skills/typo-checker/SKILL.md 与 _typos.toml你可以在自己的仓库中复刻这一整套维护实践。【免费下载链接】vitestNext generation testing framework powered by Vite.项目地址: https://gitcode.com/GitHub_Trending/vi/vitest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考