在开发项目的时候,我们要设置一些基础配置,让不同开发人员在不同环境下能写出统一规范的代码。 下面就记录下本人在使用的一些通用设置。
eslint + prettier eslint
用来进行代码的校验,prettier
用于统一代码风格
eslint
的安装和使用在之前的一篇文章中已经说明。下面介绍下 prettier
:
1 npm i -D prettier eslint-plugin-prettier eslint-config-prettier
eslint-plugin-prettier
插件会调用 prettier
对你的代码风格进行检查. 其原理是先使用 prettier
对你的代码进行格式化,然后与格式化之前的代码进行对比,如果过出现了不一致,这个地方就会被 prettier
进行标记。
通过使用 eslint-config-prettier
配置,能够关闭一些不必要的或者是与 prettier
冲突的lint选项。 这样我们就不会看到一些 error
同时出现两次。使用的时候需要确保,这个配置在 extends
的最后一项。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 { extends: [ 'standard' , 'plugin:vue/essential' , 'plugin:prettier/recommended' , ], plugins: ['prettier' ], rules: { 'no-console' : process.env.NODE_ENV === 'production' ? 'error' : 'off' , 'no-debugger' : process.env.NODE_ENV === 'production' ? 'error' : 'off' , 'prettier/prettier' : [ 'error' , { semi: false , singleQuote: true , printWidth: 120 } ] }, }
NOTE: 配置方法有好几种,本人在 .eslintrc.js
中对 prettier
进行配置
husky + lint-staged 这个在之前的文章中有介绍。
当然,现在 husky
在 package.json
提供了额外的配置参数 husky
,而不是在 script
中写 precommit
Commitizen + Commitlint 用这两个插件来让你的 git commit message 更加的规范和统一。Commitizen
是一套模版化的commit message, Commitlint
用来检查commit message 是否符合制定模板
1 2 npm install -D commitizen cz-customizable npm install -D commitlint-config-cz @commitlint/cli @commitlint/config-conventional
结合 husky
插件就能拥有同样的 git commit
命令,不一样的体验,而不是使用 git cz
命令
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // package.json { "husky" : { "hooks" : { "pre-commit" : "lint-staged" , "prepare-commit-msg" : "exec < /dev/tty && git cz --hook" , "commit-msg" : "commitlint -E HUSKY_GIT_PARAMS" } }, "lint-staged" : { "src/**/*.{js,vue}" : [ "eslint --fix" , "git add" ] }, "config" : { "commitizen" : { "path" : "cz-customizable" } } }
额外需要增加下面这些文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 'use strict' ;module .exports = { types: [ { value: 'WIP' , name : '💪 WIP: Work in progress' }, { value: 'feat' , name : '✨ feat: A new feature' }, { value: 'fix' , name : '🐞 fix: A bug fix' }, { value: 'refactor' , name : '🛠 refactor: A code change that neither fixes a bug nor adds a feature' }, { value: 'docs' , name : '📚 docs: Documentation only changes' }, { value: 'test' , name : '🏁 test: Add missing tests or correcting existing tests' }, { value: 'chore' , name : '🗯 chore: Changes that don\'t modify src or test files. Such as updating build tasks, package manager' }, { value: 'style' , name : '💅 style: Code Style, Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)' }, { value: 'revert' , name : '⏪ revert: Revert to a commit' } ], scopes: [], allowCustomScopes: true , allowBreakingChanges: ["feat" , "fix" ] };
1 2 3 4 5 6 7 8 module .exports = { extends: ['@commitlint/config-conventional' , 'cz' ], rules: { 'type-enum' : [2 , 'always' , ['WIP' , 'feat' , 'fix' , 'refactor' , 'docs' , 'test' , 'chore' , 'style' , 'revert' ]], 'type-case' : [0 , 'never' ] } }
standard-version 如果使用上面的插件来规范我们的git commit message, 那么我们就可以借助 standard-version 这样的工具, 自动生成 CHANGELOG, 甚至是 语义化的版本号(Semantic Version).
1 npm i -D standard-version
在 package.json
中配置:
1 2 3 4 5 6 { "scirpt" : { ..., "release": "HUSKY_SKIP_HOOKS=1 standard-version" } }
Note : HUSKY_SKIP_HOOKS=1
用于取消husky中第二个hook(prepare-commit-msg
),这个需要husky
升级到3.0.0
版本以上
参考
使用ESLint+Prettier来统一前端代码风格
优雅的提交你的 Git Commit Message