easy-vibe 提交 PR 前如何运行 Prettier 格式化、ESLint 与 Node 测试检查-育师

easy-vibe 提交 PR 前如何运行 Prettier 格式化、ESLint 与 Node 测试检查

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

easy-vibe 是一个基于 VitePress（Vue 3）的文档站点项目，仓库要求 Node.js>= 18。如果你准备向仓库提交 PR，需要在本地按仓库自身的约定把代码跑通：先用 Prettier 统一格式，再用 ESLint 检查docs/.vitepress/theme下的代码，最后用 Node 内置的node --test跑测试，并用构建作为主要正确性检查。AGENTS.md 明确规定npm run build是 CI 风格的检查手段，PR 需要包含简短描述、UI/组件变更的截图或 GIF，以及涉及的文件路径（例如docs/zh-cn/appendix/...、docs/.vitepress/theme/...）。

准备环境

在仓库根目录执行依赖安装：

npm install

package.json中"engines": { "node": ">=18.0.0" }声明了 Node 版本下限；devDependencies 中已包含prettier（^3.7.4）、eslint（^9.0.0）、@eslint/js、eslint-plugin-vue、vue-eslint-parser，安装后即具备运行全部检查的工具。另外package.json有"prepare": "husky"，npm install时会顺带安装 git hooks，这是后面 pre-commit / pre-push 检查的来源。

运行 Prettier 格式化

执行仓库脚本（对应prettier --write .）：

npm run format

该命令对仓库中所有文件运行 Prettier。格式细节由 .prettierrc 决定：semi: false、singleQuote: true、trailingComma: "none"，并对*.vue文件单独指定parser: "vue"、htmlWhitespaceSensitivity: "ignore"、vueIndentScriptAndStyle: false。

注意 .prettierignore 排除了**/*.md和**/*.vue，也就是说npm run format实际不会改写 Markdown 和 Vue 文件；如果你的改动集中在.vue组件上，不要依赖这条命令，而是遵循 Prettier 配置中的 Vue 规则手动保持格式一致。

AGENTS.md 对格式化还有一条约束：保持 diff 尽量小，避免把无关文件一起 reformat。所以格式化后先用git diff检查改动范围，只保留与本次 PR 相关的变更。

运行 ESLint 检查

仓库的 lint 脚本只覆盖 VitePress 主题目录（package.json中"lint": "eslint docs/.vitepress/theme"）：

npm run lint

如需自动修复可执行：

npm run lint:fix

规则来自 eslint.config.js：flat config 组合了js.configs.recommended与eslint-plugin-vue的flat/recommended，并对**/*.vue、**/*.js、**/*.ts使用vue-eslint-parser。其中几个要点：

关键 Vue 规则保持为error，如vue/no-mutating-props、vue/no-template-shadow、vue/require-v-for-key、vue/no-use-v-if-with-v-for、no-undef、no-dupe-keys；
部分规则放宽为warn（如no-unused-vars、no-control-regex、no-prototype-builtins）；
所有格式类 Vue 规则被off（vue/html-indent、vue/singleline-html-element-content-newline等），注释写明格式化交给 Prettier 处理——所以 ESLint 报错里出现的是逻辑问题，格式问题应交给 Prettier。

判断标准：退出码为 0 且输出中没有✖ ... error即通过；warnings 不阻断提交（这与 pre-commit 钩子的行为一致，见下文）。

运行 Node 测试

package.json提供了基于 Node 内置node --test的测试脚本：

npm test

其实际命令为node --test $(find docs scripts -name '*.test.js' -print)，即在docs与scripts目录下查找所有*.test.js并逐一运行；当前仓库中匹配的测试文件是 docs/.vitepress/theme/utils/readingBookmark.test.js。另有更严格的覆盖率版本，要求行、分支、函数覆盖率达到 100%：

npm run test:coverage

这里说明一下文档间的口径：AGENTS.md 称仓库没有专门的测试框架，把npm run build作为主要正确性检查，交互式组件通过npm run dev手动验证；package.json中的test脚本则基于 Node 自带node:test。两者并不冲突：node --test是 Node 内置能力而非第三方框架，因此提交前既跑npm test，也跑构建，才符合仓库约定。

用构建作为正确性检查

AGENTS.md 明确把生产构建当作 CI 式检查：

npm run build

它执行node scripts/build-locales.mjs。构建成功是 PR 前最重要的判定之一——pre-commit 与 pre-push 钩子都会强制执行构建，见下一节。

Husky 钩子如何自动执行这些检查

npm install时prepare脚本安装了 husky 钩子，提交和推送时会自动跑检查，无需手动重复执行，但了解其行为可以提前预判拦截原因：

.husky/pre-commit：先用git diff --cached判断暂存区是否有.vue文件，没有 Vue 文件变更时直接跳过所有检查；有 Vue 文件时依次运行npm run lint（只把 ESLint 输出中的 error 当作失败，warnings 忽略）和npm run build，任一失败则阻止提交。
.husky/pre-push：执行SITEMAP_NO_WRITE=1 npm run build:force，强制全量构建失败时阻止推送。

钩子在失败时会提示跳过方式（git commit --no-verify/git push --no-verify）。仅当确认变更不需要跑完整检查时才使用，否则修复后重新提交。

提交 PR 前的核对顺序

一条最短可执行的主路径：

npm install npm run format npm run lint npm test npm run build

逐项判断：npm run format后git diff只应出现与本次改动相关的格式调整；npm run lint无 error；npm test中各*.test.js全部通过；npm run build成功。全部通过后按 AGENTS.md 的约定写提交信息（feat:、fix:、docs:等 Conventional Commits 风格，可带 scope 如feat(docs): ...），并在 PR 中附上简短描述、涉及的 UI/组件变更截图或 GIF、以及本次触碰的路径列表。若暂存了.vue文件，commit 时 pre-commit 钩子会自动再跑 lint（仅 error）与 build；push 时 pre-push 钩子会再做一次强制构建，本地已通过的检查能显著减少被钩子打回的次数。

【免费下载链接】easy-vibe💻 vibe coding 101｜The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考