前端代码规范
一千个读者，有一千个哈姆雷特
一千个程序员，就有一千种代码风格
由于个人喜好、习惯、编码风格各异，因此团队合作中需要统一规范
前端代码规范流程实践思路
- 本地开发过程，提示、校验、更改
- Git 提交过程，代码校验是否允许提交
- 服务端校验，代码校验是否合并和发布
一、开发者本地IDE统一
开发工具统一配置，智能实时提示
以 VS COde 为例， 安装 ESLint，Vetur 等扩展包
规则设置
项目构建时 lint 规则可以继承优秀团队基于最佳实践设定的编码规范，如 airbnb, 这样避免重复造轮子造成人力的资源浪费和规则覆盖的缺陷，继承社区知名代码规范后团队内部再进行细节调整
{ "extend": ["airbnb-base"], "rules": { "semi": ["error", "never"] } }
社区知名的代码规范
- eslint-config-airbnb
(github.com/airbnb/java…) - eslint-config-standard
(github.com/standard/es…) - eslint-config-alloy
(github.com/AlloyTeam/e…)
vue-cli3 脚手架初始化项目时规范选择
可以设置部分 eslint rule 为警告，保障开发体验，并且在 pre-commit 与 CI 中把警告视为不通过，保证严格的代码规范
二、 Git Hooks
团队合作中的编码规范有一点是，虽然自己有可能不舒服，但是不能让别人因为自己的代码而不舒服。
git 自身包含许多 hooks，在 commit，push 等 git 事件前后触发执行。与 pre-commit hook 结合可以帮助校验 Lint，如果非通过代码规范则不允许提交。
husky 是一个使 git hooks 变得更简单的工具，只需要配置几行 package.json 就可以愉快的开始工作。
// package.json { "scripts": { "lint": "eslint . --cache" }, "husky": { "hooks": { "pre-commit": "npm lint", } } }
git commit 过程拦截效果
注意：git hooks 的规范校验可以通过 git commit -n 跳过，需要在 CI 层继续加强校验
三、 CI/CD
git hooks 可以绕过，但 CI(持续集成) 是绝对绕不过的，因为它在服务端校验。使用 gitlab CI 做持续集成，配置文件 .gitlab-ci.yaml 如下所示
lint: stage: lint only: - /^feature\/.*$/ script: - npm run test
GitLab pipelines 运行效果
资料参考
以下资料为2020年以后日期发布的内容
