代码质量CI/CD【免费下载链接】super-linterCombination of multiple linters to run as a GitHub Action or standalone项目地址https://gitcode.com/gh_mirrors/su/super-linter点击查看免费下载NATURAL_LANGUAGE 是 super-linter 中专门用于对 Markdown 文档进行自然语言拼写与文风检查的 lint 语言模块其底层引擎为 textlint。本文围绕该模块在 super-linter 中的完整工作链路展开从测试用例的设计意图bad/good 文件到源码中文件的收集、规则配置文件的解析再到 textlint 命令的实际拼装帮助你理解如何在 CI 中为中文/英文文档配置并启用自然语言检查并掌握从仓库源码定位配置与验证行为的方法。该模块解决的痛点Markdown 拼写与文风问题在软件开发流程中代码本身可以被各种 linter 约束但仓库里的 Markdown 文档README、CHANGELOG、docs 等却常常缺乏自动化质量保障。自然语言文档中最常见的两类问题拼写/大小写错误例如把JavaScript写成Javascript、changelogs写成change logs专有名词与术语不统一例如source maps与source-maps混用。super-linter 的 NATURAL_LANGUAGE 模块正是为这类问题而生它借助 textlint 对 Markdown 文本进行规则化校验让文档质量和代码质量一样可控。测试用例设计bad 与 good 文件如何定义“对与错”super-linter 的每个语言模块在 test/linters 下都维护一套测试用例命名约定如下文件名或路径中包含good的用例应通过校验包含bad的用例应被判定为失败。NATURAL_LANGUAGE 模块的两个测试文件恰好展示了 textlint 能捕获的真实问题test/linters/natural_language/natural_language_bad_01.md期望 lint 失败内容如下My **Javascript** is good Write change logs about source-mapstest/linters/natural_language/natural_language_good_01.md期望 lint 通过内容如下My **JavaScript** is good Write changelogs about source maps对照两个文件可以清晰看出该模块的校验目标问题类型bad 文件写法good 文件写法专有名词大小写JavascriptJavaScript复合词/连字符用法source-mapssource maps词汇拼写change logschangelogs从 test/linters/README.md 可知测试只关注 super-linter 如何调用每个 linter 及其退出码不校验 linter 的具体输出内容——这是各 linter 自身职责。因此这两个文件本质上是给“super-linter 是否把 Markdown 交给 textlint 并正确传播退出码”做回归验证。文件收集哪些 Markdown 会进入 NATURAL_LANGUAGE 队列NATURAL_LANGUAGE 检查的输入由 lib/functions/buildFileList.sh 决定。在文件类型分发的elif链中md扩展名分支如下见 buildFileList.sh 第 706-713 行elif [ ${FILE_TYPE} md ]; then echo ${FILE} ${FILE_ARRAYS_DIRECTORY_PATH}/file-array-MARKDOWN if IsNotSymbolicLink ${FILE}; then echo ${FILE} ${FILE_ARRAYS_DIRECTORY_PATH}/file-array-MARKDOWN_PRETTIER else debug Skip adding ${FILE} to MARKDOWN_PRETTIER file array because Prettier doesnt support following symbolic links fi echo ${FILE} ${FILE_ARRAYS_DIRECTORY_PATH}/file-array-NATURAL_LANGUAGE可以看出每个.md文件会同时进入 MARKDOWNmarkdownlint、MARKDOWN_PRETTIERPrettier与 NATURAL_LANGUAGEtextlint三个文件数组三者互不替代与 Prettier 分支不同NATURAL_LANGUAGE 不排除符号链接文件即所有被检测到的.md文件都会进入 textlint 检查队列文件是否进入该队列与是否自定义规则无关属于全局文件发现流程的一部分。规则配置.textlintrc的查找与回退机制NATURAL_LANGUAGE 的规则文件默认名为.textlintrc这一默认值定义在 lib/globals/linterRules.sh 第 106 行NATURAL_LANGUAGE_FILE_NAME${NATURAL_LANGUAGE_CONFIG_FILE:-.textlintrc}也就是说你可以通过环境变量NATURAL_LANGUAGE_CONFIG_FILE覆盖默认文件名。而规则文件的实际路径解析逻辑在 lib/functions/linterRules.sh 的LinterRules函数中见第 16-73 行其核心行为若LINTER_RULES_PATH为.或/则将其置空第 6-7 行即不再拼接子目录当LINTER_RULES_PATH非空时规则路径解析为${GITHUB_WORKSPACE}/${LINTER_RULES_PATH}/${NATURAL_LANGUAGE_FILE_NAME}第 36 行当LINTER_RULES_PATH为空时回退到镜像内置路径${DEFAULT_RULES_LOCATION}/${NATURAL_LANGUAGE_FILE_NAME}第 49 行其中DEFAULT_RULES_LOCATION在 lib/globals/linterRules.sh 第 5 行 定义为/action/lib/.automation若解析出的规则文件不存在除 Java 的少数内置兜底外会调用fatal终止第 70 行保证配置缺失时快速失败而不是静默降级。LINTER_RULES_PATH的默认值是.github/linterslib/globals/linterRules.sh 第 8 行这也是绝大多数 super-linter 语言模块共用的规则目录约定。因此在你的仓库中放置.github/linters/.textlintrc即可让该配置对 NATURAL_LANGUAGE 生效。命令拼装textlint 如何被调用NATURAL_LANGUAGE 的实际执行命令定义在 lib/functions/linterCommands.sh 第 216 行LINTER_COMMANDS_ARRAY_NATURAL_LANGUAGE(textlint -c ${NATURAL_LANGUAGE_LINTER_RULES})这条命令与相邻的 MARKDOWN 命令markdownlint -c ...保持一致的风格通过-c显式指定配置文件路径即上一步LinterRules函数解析出的${NATURAL_LANGUAGE_LINTER_RULES}变量值其余参数由 worker 统一追加。因此最终对每个.md文件执行的实质命令为textlint -c 规则文件路径 markdown文件此外在 lib/globals/linterCommandsOptions.sh 第 78 行 中定义了修复模式选项NATURAL_LANGUAGE_FIX_MODE_OPTIONS(--fix)当开启 super-linter 的 FIX_MODE 时textlint 会以--fix参数运行自动修复可自动处理的拼写/文风问题不可自动修复的问题仍会以失败退出。这是该模块与普通 lint 模式最大的行为差异。工作流全景与实操建议综合以上源码证据NATURAL_LANGUAGE 的完整工作链路为文件发现buildFileList.sh收集所有 .md → 规则定位linterRules.sh解析 .textlintrc → 命令拼装linterCommands.shtextlint -c ... → 执行与退出码传播worker → 失败时产出检查报告实操要点总结如下启用方式无需额外开关任何.md文件默认都会被 NATURAL_LANGUAGE 检查若想跳过可结合 super-linter 的 FILTER_REGEX_INCLUDE/EXCLUDE 配置但这会同时影响其他模块的文件收集。自定义规则在仓库根目录创建.github/linters/.textlintrcJSON 格式的 textlint 配置即可替换镜像内置默认配置如不想使用该默认目录可通过LINTER_RULES_PATH与NATURAL_LANGUAGE_CONFIG_FILE两个环境变量调整查找位置与文件名。配置缺失行为若解析出的.textlintrc不存在super-linter 会直接fatal终止而不是跳过因此使用自定义规则前务必保证文件真实存在。修复模式在 FIX_MODE 下 textlint 会以--fix运行可对部分拼写问题自动修复建议将 bad/good 两个测试用例natural_language_bad_01.md 与 natural_language_good_01.md作为本地验证的最小样例。回归验证若你 fork 或扩展了 NATURAL_LANGUAGE 相关逻辑可运行 test/run-super-linter-tests.sh 中对应的测试套件确认 textlint 的退出码被正确传播。综上NATURAL_LANGUAGE 是 super-linter 中文本即代码理念的具体落地通过统一的文件收集、规则定位与命令拼装机制把 textlint 无缝接入 GitHub Action 的 lint 流水线让 Markdown 文档的拼写、大小写与术语风格在合并前就能被自动化拦截。赞分享代码质量CI/CD【免费下载链接】super-linterCombination of multiple linters to run as a GitHub Action or standalone项目地址https://gitcode.com/gh_mirrors/su/super-linter点击查看免费下载相关推荐Super-Linter 的 Markdown 检查实战基于 markdownlint 的规范写法与规则配置解析Super Linter 的 Markdown 检查实战基于 markdownlint 的规范写法与规则配置解析 导读 本文以 super linter 仓库代码质量CI/CD如何构建智能AI记忆系统终极完整指南让AI从经验中学习和成长如何构建智能AI记忆系统终极完整指南让AI从经验中学习和成长 在当今AI技术快速发展的时代大多数AI系统面临着一个根本性挑战它们无法真正从经验中学习。传统人工智能AI AgentAgent 记忆MCP 服务Super-Linter多语言代码规范和风格检查工具Super Linter多语言代码规范和风格检查工具 Super Linter 是一个开源项目旨在为多种编程语言提供代码规范和风格检查。该项目主要通过 Py代码质量CI/CD上一篇ncmdump网易云音乐NCM格式解密技术深度解析下一篇NCM解密工具实战从格式限制到音乐自由的完整解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考