每个人都有自己的代码书写风格，当团队协作的时候，如果每个人都坚持自己的风格书写，代码将是灾难性的。所以我们需要统一风格，不仅可以减少出虫的几率，而且能增加代码的可读性。
/ 代码规范 /
对前端而言，通常我们会配置eslint ，tslint ，stylelint 等代码检查工具，来帮我们制定代码校验规则。这里拿 tslint 和 stylelint 举例，分别对 typescript 和 scss 进行代码检查。
npm install tslint stylelint --save-dev
在项目根目录下面分别创建 tslint.json和.stylelintrc 文件。然后你就可以像下面这样去定义规则。
// tslint.json
{
"rules": {
"arrow-return-shorthand": true,
"indent": [
true,
"spaces"
],
"max-line-length": [
true,
140
],
"no-trailing-whitespace": true,
"no-unnecessary-initializer": true,
"no-unused-expression": true,
"no-use-before-declare": true,
"no-var-keyword": true,
"prefer-const": true,
"quotemark": [
true,
"single"
],
"semicolon": [
true,
"never"
],
"triple-equals": [
true,
"allow-null-check"
],
"typedef-whitespace": [
true,
{
"call-signature": "nospace",
"index-signature": "nospace",
"parameter": "nospace",
"property-declaration": "nospace",
"variable-declaration": "nospace"
}
],
"unified-signatures": true,
"variable-name": false,
"whitespace": [
true,
"check-branch",
"check-decl",
"check-operator",
"check-separator",
"check-type"
],
}
}
// .stylelintrc
{
"rules": {
"no-empty-source": null,
"selector-pseudo-element-no-unknown": [
true,
{
"ignorePseudoElements": ["ng-deep"]
}
]
}
}
lint检查工具一般会有一些通用的配置，下载后就可以使用，比较有名的像AirBnb的lint检查规范。在tslint和stylelint中也可以直接使用官方推荐的规范：
npm install stylelint-config-standard --save-dev
// tslint.json
{
"extends": ["tslint:recommended"],
"rules": {
// ...rules
}
}
// .stylelintrc
{
"extends": ["stylelint-config-standard"],
"rules": {
// ...rules
}
}
针对代码风格问题，还可以引入prettier来帮助格式化代码，prettier主要优点是对几乎所有前端的代码都可以优化，比如html，css，scss，jsx，ts等。所以所有的代码风格的校验可以都交给prettier，让它完成代码风格的格式化，而lint工具主要专注于代码质量的检查。
npm install prettier --save-dev
// .prettierrc
{
"singleQuote": true,
"printWidth": 120,
"semi": false,
"tabWidth": 2,
"useTabs": false,
"overrides": [
{
"files": ".prettierrc",
"options": {
"parser": "json"
}
}
]
}
因为prettier内置了一套代码风格，而且只暴露很少的可配置项，所以为了防止lint工具和prettier冲突，还需要安装相应的库：
npm prettier-stylelint tslint-config-prettier --save-dev
// tslint.json
{
"extends": ["tslint-config-prettier"],
"rules": {
// ...rules
}
}
// .stylelintrc
{
"extends": ["stylelint-config-standard", "prettier-stylelint"],
"rules": {
// ...rules
}
}
配置完后，我们可以通过 脚本 帮我们快速格式化代码：
// package.json
{
"scripts": {
"format": "npm run prettier && npm run lint:ts && npm run lint:style",
"prettier": "prettier --config ./.prettierrc --write 'src/**/!(polyfills).{ts,scss}'",
"lint:ts": "tslint -c tslint.json 'src/app/**/!(demo|testing)/!(polyfills).ts' --fix",
"lint:style": "stylelint \"src/app/**/*.scss\" --fix",
}
}
这时候只要每次提交代码之前，运行npm run format就可以帮我们进行代码检查。
但是，这时候有个问题，如果你忘了运行这个命令，你还是可以提交，流程之中就存在漏洞。此时就可以请出husky和lint-staged，利用git的勾来帮我们在commit前自动进行代码检查。
npm husky lint-staged --save-dev
// package.json
{
// ...
"lint-staged": {
"src/app/**/!(demo|testing)/!(polyfills).{ts,scss}": [
"prettier --config ./.prettierrc --write",
"git add"
],
"src/app/**/!(demo|testing)/!(polyfills).ts": [
"tslint -c tslint.json --fix",
"git add"
],
"src/app/**/*.scss": [
"stylelint \"src/app/**/*.scss\" --fix",
"git add"
]
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
}
},
}
husky会在.git / hooks中写入pre-commit的钩子，这个钩子会在git commit执行的时候触发，而lint-staged会对此时在暂存区的文件进行lint和prettier检查，并且会自动修复一些能修复的问题，并重新添加到暂存区。这时候如果检查通过，会设暂存区中的文件提交;检查不过关，则会终止提交操作。
/ commit规范 /
git可以帮我们很好地管理代码，但是在多人合作的时候，经常会碰到各种随意的提交信息，当你需要会看提交消息的时候，就会很头疼。
首先来看一下被业界广泛认可的Angular commit message规范。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
一个提交消息由三部分构成：
标题行：必填，描述主要修改类型和内容
主题内容：描述为什么修改，做了什么样的修改，以及开发的思路等等
页脚注释：放断裂的变化或已解决的问题
在这三部分中，<>中的内容分别表示：
type：commit的类型
feat：新特性
修复：修改问题
refactor：代码重构
docs：文档修改
style：代码格式修改，注意不是css修改
test：测试用例修改
家务：其他修改，比如构建流程，依赖管理。
pref：性能提升的修改
build：对项目构建或者依赖的改动
ci：CI的修改
恢复：恢复前一个提交
范围：commit影响的范围，比如：route，component，utils，build ...
subject：commit的概述，建议符合 50/72格式
body：commit具体修改内容，可以分为多行，建议符合50/72格式化
footer：一些备注，通常是BREAKING CHANGE或修复的bug的链接。
这时候我们需要工具像lint检查一样来帮我们约束commit message的书写。
npm install commitizen cz-conventional-changelog @commitlint/config-conventional @commitlint/cli --save-dev
commitizen会代替你的git commit，cz-conventional-changelog是一个符合Angular commit message规范的预设，@ commitlint / config-conventional则是校验规则。
这里同样需要借助husky和lint-staged：
// package.json
{
"scripts": {
// ...
"commit": "git-cz"
}
// ...
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
},
"husky": {
"hooks": {
"pre-commit": "lint-staged",
"commit-msg": "commitlint -e $GIT_PARAMS"
}
},
}
// .commitlintrc.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [
2,
'always',
["feat", "fix", "docs", "style", "refactor", "chore", "publish"]
],
'subject-case': [0, 'never'],
},
}
这时候你就可以用git cz代替git commit，当然如果习惯了提交消息规范后，可以直接用git commit，如果message不符合规范，是不会提的。
/ 总结 /
代码规范和提规范是前端工程化中的重要一环，工程化可以保证在多人协作的情况下，项目质量的下限。
多年编程经验，今年1月整理了一批2019年最新WEB前端教学视频，不论是零基础想要学习前端还是学完在工作想要提升自己，这些资料都会给你带来帮助，从HTML到各种框架，帮助所有想要学好前端的同学，学习规划、学习路线、学习资料、问题解答。只要加入WEB前端学习交流qun：296，212，562，即可免费获取，学习不怕从零开始，就怕从不开始。
网友评论