在Ubuntu下进行JavaScript代码审查,组合ESLint、Prettier、Husky与Lint-Staged实现Git钩子自动化,集成CI/CD自动检查,辅以单元测试及第三方服务,形成完整流程。
在Ubuntu环境下进行JavaScript代码审查,看似复杂,但只要理清核心工具和流程,整套方案就能高效运行。以下内容可先帮助建立整体印象,后续将逐步展开。

长期稳定更新的攒劲资源: >>>点此立即查看<<<
ESLint几乎是JavaScript/React项目的标配。它不仅能揪出语法错误、风格不一致的问题,还能发现未使用的变量、不安全的DOM操作等潜在隐患,且规则高度可定制。
npm install eslint --save-dev;接着运行 npx eslint --init,根据提示选择“Use a popular style guide”或“Answer questions about your style”,即可生成 .eslintrc.js 或 .eslintrc.json 配置文件。npx eslint . 扫描当前目录及所有子目录的JS文件,或指定 npx eslint src/ 只检查 src 目录。终端会直接输出错误和警告信息,如 no-unused-vars 表示某个变量已声明但未使用。代码风格争议往往消耗团队大量精力。Prettier专门解决此问题——它只统一缩进、引号、分号、换行等格式,与ESLint配合,各司其职。
npm install --save-dev prettier,然后在项目根目录创建 .prettierrc 文件,例如 { "semi": true, "singleQuote": true, "tabWidth": 2 }。npx prettier --write "src/**/*.{js,jsx}",即可一键格式化 src 目录下所有JS/JSX文件。手动检查难免遗漏,最佳方案是将审查流程嵌入Git提交环节。Husky可设置Git钩子(如 pre-commit),在提交前自动运行ESLint和Prettier;Lint-Staged则只检查暂存区文件,速度更快。
npm install husky lint-staged --save-dev。"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"*.{js,jsx}": [
"eslint --fix", // 自动修复可修复的问题
"prettier --write", // 格式化代码
"git add" // 将修复后的文件重新加入暂存区
]
}
这样每次 git commit 时,会自动触发ESLint修复和Prettier格式化,只有合规代码才能被提交。要确保主分支代码质量,将审查流程整合到CI/CD中最为稳妥。每次推送(push)或发起拉取请求(Pull Request)时自动运行检查,能有效拦截问题代码。
.github/workflows 下创建 code-review.yml,内容如下:
name: Code Review Workflow
on:
push:
branches: ["main"] # 推送至main分支时触发
pull_request:
branches: ["main"] # 创建针对main分支的PR时触发
jobs:
review:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'yarn' # 缓存yarn依赖,加速安装
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Run ESLint and Prettier
run: npm run lint # 执行package.json中的lint脚本(需提前配置)
package.json 中添加:
"scripts": {
"lint": "eslint src/ --ext .js,.jsx && prettier --check 'src/**/*.{js,jsx}'"
}
该脚本同时检查ESLint错误和Prettier格式问题。除自行搭建工具外,还可借助成熟的SaaS服务。
若团队有特殊编码规范,如“函数参数不超过3个”或“禁止使用 alert”,可通过自定义ESLint规则实现精准控制。
eslint/rules/custom-rule.js,编写规则逻辑,例如检查函数参数数量:
module.exports = {
meta: {
type: 'suggestion',
docs: {
description: '限制函数参数数量不超过3个',
category: 'Best Practices',
recommended: false
},
schema: [{ type: 'integer', minimum: 1 }],
messages: {
tooManyParams: '函数参数过多({{count}}个),最多允许{{max}}个。'
}
},
create(context) {
const maxParams = context.options[0] || 3;
return {
FunctionDeclaration(node) {
if (node.params.length > maxParams) {
context.report({
node,
messageId: 'tooManyParams',
data: { count: node.params.length, max: maxParams }
});
}
},
FunctionExpression(node) {
if (node.params.length > maxParams) {
context.report({
node,
messageId: 'tooManyParams',
data: { count: node.params.length, max: maxParams }
});
}
}
};
}
};.eslintrc.js 中引入自定义规则:
module.exports = {
rules: {
'custom-rule': ['error', 3]
},
plugins: ['custom-plugin'] // 需要创建eslint/plugins/custom-plugin/index.js导出规则
};
最后用 eslint --print-config . 验证自定义规则是否生效。代码审查不仅关注风格和潜在错误,功能正确性同样重要。引入单元测试框架(如Jest)能让审查更全面。
npm install --save-dev jest。__tests__/example.test.js 文件,例如测试一个加法函数:
const add = require('../src/add');
test('adds 1 + 2 to equal 3', () => {
expect(add(1, 2)).toBe(3);
});npm test,Jest会输出通过/失败的用例数量,一目了然。从静态分析、格式化、自动钩子,到CI/CD集成、第三方服务、自定义规则,再到单元测试,这套组合覆盖了Ubuntu环境下的JavaScript代码审查核心场景。可根据项目实际需求,选择其中几个环节组合使用,不必全部照搬。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述