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

easy-vibe 提交 PR 前如何运行 Prettier 格式化、ESLint 与 Node 测试检查【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibeeasy-vibe 是一个基于 VitePressVue 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 installpackage.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: huskynpm 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/themenpm run lint如需自动修复可执行npm run lint:fix规则来自 eslint.config.jsflat 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 规则被offvue/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_WRITE1 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无 errornpm 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与 buildpush 时 pre-push 钩子会再做一次强制构建本地已通过的检查能显著减少被钩子打回的次数。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考