前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载导读本文围绕 wp-calypsoWordPress.com 的 JavaScript 与 API 前端仓库的编码规范文档 docs/coding-guidelines/trailing-whitespace.md 展开系统讲解所有源文件必须清除行尾尾随空白这一基础但极易被忽视的规范为什么必须清除、如何借助编辑器自动完成、如何在 CI/提交前用工具强制约束以及触碰旧代码时如何用独立 commit 保证历史可读性。读完本文你将掌握在 wp-calypso 这类大型单仓库monorepo中彻底消灭尾随空白的完整工作流从编辑器配置、仓库级 .editorconfig 约束到 Prettier/ESLint 自动化一应俱全。一、规范原文一句话原则与三条实操要求trailing-whitespace.md 全文的核心原则只有一句All source files should have trailing whitespace removed.所有源文件都应清除行尾尾随空白。在此基础上原文档给出了三条可落地的实操要求编辑器自动清除Sublime Text 用户可通过设置trim_trailing_whitespace_on_save: true在保存时自动清除尾随空白。其他编辑器方案Coda2 用户可安装 Whiteout 插件原文档给出的插件地址。触碰旧代码的提交纪律当修改尚未清理尾随空白的旧代码时先用一个独立的 commit 完成清理再开始正式改动这样后续改动在 Git 历史中一目了然。这一规范并非孤立存在它被 docs/coding-guidelines/javascript.mdNo whitespace at the end of line or on blank lines第 10 行与 docs/coding-guidelines/css.md第 296 行等语言规范反复引用并统一指向 trailing-whitespace.md可见它是整个仓库代码审查中最底层的卫生基线。二、为什么尾随空白必须清除藏在 diff 里的噪声尾随空白指的是每行末尾、在换行符之前残留的空格或 Tab。它肉眼几乎不可见却在版本控制中制造真实的麻烦污染 diff一次只改动一行代码却因为相邻行的尾随空格被无意删掉diff 里出现成片无关改动代码审查者被迫在真实改动与空白噪声之间反复分辨。干扰工具链部分 lint 规则、构建脚本、diff 工具对行尾敏感在 wp-calypso 的 Git 工作流见 docs/git-workflow.md中干净的 diff 是 review 高效的前提。破坏可追溯性wp-calypso 大量使用git blame定位改动来源例如排查性能回归时尾随空白的删除与真实逻辑改动混在同一个 commit 里会让 blame 结果失真。这正是原文档要求清理与改动分开提交的根本原因先提交纯格式清理该 commit 内只有空白变化再提交真实功能改动历史中每一个 commit 的意图都保持单一、可解释。三、编辑器层保存即清除的自动化配置Sublime Text原文档方案按原文档指引打开SublimeText 2 Preferences Settings - UsermacOS 上可直接按Cmd ,在用户设置 JSON 中加入{ trim_trailing_whitespace_on_save: true }保存后每次保存文件都会自动剥离所有行尾尾随空白。需注意建议保留或显式设为true的还有ensure_newline_at_eof_on_save它与 wp-calypso 的另一条规范文件必须以换行符结尾见 docs/coding-guidelines/newline-at-end-of-file.md配套二者共同保证源文件的行级卫生。其他主流编辑器速查编辑器配置方式关键项VS Codesettings.jsonfiles.trimTrailingWhitespace: true默认仅对无语法文件生效建议全局开启Coda 2安装 Whiteout 插件保存时清除尾随空白Atomwhitespace核心包设置removeTrailingWhitespace默认开启Vim.vimrcautocmd BufWritePre * :%s/\s\$//e或使用set list高亮显示行尾空白nano默认行为不会自动删除需自行留意以 VS Code 为例为 wp-calypso 配置后settings.json可写为{ files.trimTrailingWhitespace: true, files.insertFinalNewline: true }四、仓库层.editorconfig 的强制基线wp-calypso 仓库根目录的 .editorconfig 是整个项目的统一编辑器配置它把清除尾随空白从个人习惯上升为仓库级约定root true [*] # yes, we use tabs indent_style tab indent_size 4 end_of_line lf charset utf-8 trim_trailing_whitespace true insert_final_newline true [*.md] trim_trailing_whitespace false [*.yml] indent_size 2 indent_style space结合本文主题这份文件值得逐条解读trim_trailing_whitespace true全局块所有源码文件保存时自动删除行尾空白与 trailing-whitespace.md 的规范一一对应是仓库级的第一道防线。insert_final_newline true保存时确保文件末尾有换行呼应 docs/coding-guidelines/newline-at-end-of-file.md其中还提到cat命令输出时提示符会被粘到末行、以及eol-last规则。end_of_line lf统一行尾为 LF配合 GitHub 上的 diff 展示与 CI 环境Linux 服务器渲染保持一致。例外规则[*.md]下trim_trailing_whitespace falseMarkdown 文档中行尾双空格在部分 Markdown 方言里表示强制换行因此仓库特意为.md关闭自动修剪避免破坏有意书写的换行语义——这也是理解规范允许例外的典型样例。[*.yml]的 2 空格缩进YAML 对缩进敏感仓库为.yml单独规定indent_style space与indent_size 2。安装 EditorConfig 插件后VS Code、Sublime Text、JetBrains 系等主流编辑器都会在打开 wp-calypso 仓库时自动读取该文件并应用上述规则无需每个开发者手工重复配置。五、工具链层Prettier 与 ESLint 的自动化兜底编辑器与 .editorconfig 覆盖的是本机保存时刻而提交前/CI 阶段的自动格式化与 lint 才是最终兜底。Prettier格式化即清除wp-calypso 根目录的 .prettierrc 定义了全仓库统一的格式化规则useTabs: true tabWidth: 2 printWidth: 100 singleQuote: true bracketSpacing: true parenSpacing: true bracketSameLine: false semi: true trailingComma: es5Prettier 的设计哲学是输出即规范——prettier --write会自动删除所有行尾尾随空白、统一引号/分号/逗号风格。文档 docs/coding-guidelines/newline-at-end-of-file.md 也明确指出 Prettier by design 会在文件末尾补上新行。因此在 wp-calypso 中执行格式化即可顺带完成尾随空白清理# 格式化全部源码会清除尾随空白并补行尾换行 npx prettier --write client/**/*.{js,jsx,ts,tsx} # 仅检查而不改写适合 CI 门禁 npx prettier --check client/**/*.{js,jsx,ts,tsx}ESLintno-trailing-spaces规则兜底从仓库结构看wp-calypso 通过 packages/eslint-plugin-wpcalypso内含recommended配置见 packages/eslint-plugin-wpcalypso/lib/configs/recommended.js扩展 eslint-config-wpcalypso 体系。在 JavaScript/TypeScript 源文件上ESLint 核心规则no-trailing-spaces会把行尾存在空白直接判为 error从而在yarn lint或 CI 中阻止尾随空白进入主干# 运行仓库的 lint 检查依赖根 package.json 中的脚本配置 yarn lint需要特别说明的是no-trailing-spaces与 i18n 场景并不冲突——packages/eslint-plugin-wpcalypso/docs/rules/i18n-no-collapsible-whitespace.md 约束的是翻译文案内部不可折叠的空白字符与行尾空白属于两个完全不同的层面前者保护用户可见文案后者维护源码可读性。三层防线小结防线载体作用时机作用编辑器配置Sublime/VS Code 用户设置每次保存即时清除行尾空白仓库级约束.editorconfig打开仓库即生效统一缩进、行尾、换行与修剪规则自动化兜底.prettierrc ESLintno-trailing-spaces提交前 / CI强制清理并阻断违规合入六、Git 提交纪律先清理、后改动原文档的最后一段是本规范中最有工程价值的一条When touching code that does not have trailing whitespace trimmed, make a separate commit that does the stripping before starting to make changes.具体操作模板如下# 1. 先提交纯清理该 commit 只包含尾随空白删除不含任何逻辑变化 git add -u git commit -m Clean trailing whitespace # 2. 再开始并提交真正的功能改动 git commit -am Implement feature X这样做的好处有三点均可以在 wp-calypso 的日常 review 中直接验证diff 纯净审查者看到的每个 commit 只有单一意图功能改动不会被空白噪声淹没对比 docs/git-workflow.md 中对小步提交、清晰历史的一贯要求。blame 准确git blame定位到的是真实逻辑 commit而不是混杂的清理改动排查问题时少一层干扰。回滚安全一旦功能 commit 需要 revert空白清理 commit 仍可保留不会产生格式回潮。若仓库开启了 CI lint 门禁未清理的尾随空白会在合入前直接失败届时先清理后改动不再只是建议而是合入的硬性前提。七、快速自查清单在提交 wp-calypso 相关代码前对照以下清单确认尾随空白已彻底清除编辑器已开启保存时修剪尾随空白或安装了 EditorConfig 插件读取仓库根 .editorconfig改动文件已通过npx prettier --write或编辑器格式化本地yarn lint通过无no-trailing-spaces报错触碰旧代码时空白清理与功能改动分为两个独立 commit留意[*.md]例外Markdown 行尾双空格是合法的强制换行语法不应被自动清除把上述任何一步固化进自己的工作流尾随空白将不再以隐形 diff 噪声的形式消耗 wp-calypso 代码审查的注意力。赞分享前端CMS【免费下载链接】wp-calypsoThe JavaScript and API powered WordPress.com项目地址https://gitcode.com/gh_mirrors/wp/wp-calypso点击查看免费下载相关推荐PHP CS Fixer 的 no_trailing_whitespace 规则彻底清除 PHP 代码行尾空白PHP CS Fixer 的 no_trailing_whitespace 规则彻底清除 PHP 代码行尾空白 导读 no_trailing_whitespa开发工具代码质量静态分析Lint格式化PHP-CS-Fixer 规则详解no_whitespace_in_blank_line 清除空行行尾空白PHP CS Fixer 规则详解no_whitespace_in_blank_line 清除空行行尾空白 导读 no_whitespace_in_blank开发工具代码质量静态分析Lint格式化推荐使用 Trailing Spaces 插件高效清理代码尾随空格推荐使用 Trailing Spaces 插件高效清理代码尾随空格 项目介绍 Trailing Spaces 是一款专为 Sublime Text http:创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考