代码格式化

Prettier是一个支持多语言的代码格式工具，如常用的：js、jsx、Vue、Flow、Ts、HTML、CSS等，非常全面，将代码解析为AST，然后重新组装，目的是最终输出风格统一的代码，对比eslint对error的fix要强一些，如最大长度的改动，eslint只是对有问题的地方进行格式化修改，不改动源代码风格，而prettier是对全量的代码进行格式化。安装npm install –save-dev prettier配置// package.json{ “husky”: { “hooks”: { “pre-commit”: “lint-staged” } }, “lint-staged”: { “*.{js,json,css,md}”: [“prettier –write”, “git add”] }}这里我们结合之前用到的husky、lint-staged，默认prettier是直接标准输出到终端的，–write，这个配置代表直接改写文件。这里有个官网的例子foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());格式化之后foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());prettier让我们专注于业务逻辑，无需再纠结代码风格，配合其它工具，实现了代码提交到仓库前，统一格式化。

在我们介绍了Husky、Commitlint之后，来看一个前端文件过滤的工具Lint-staged，代码的格式化肯定会涉及到文件系统，一般工具会首先读取文件，格式化操作之后，重新写入。对于较大型的项目，文件众多，首先遇到的就是性能问题，虽然如Eslint之类的也有文件过滤配置，但毕竟还是对于匹配文件的全量遍历，如全量的.js文件，基本达不到性能要求，有时还会误格式化其他同学的代码，因此我们引入Lint-staged，一个仅仅过滤出Git代码暂存区文件(被committed的文件)的工具。安装npm install –save-dev lint-staged husky配置首先明确一下，Lint-staged仅仅是文件过滤器，不会帮你格式化任何东西，所以没有代码规则配置文件，需要自己配置一下，如：.eslintrc、.stylelintrc等，然后在package.json中引入。{ “husky”: { “hooks”: { “pre-commit”: “lint-staged” } }, “lint-staged”: { “.js”: [“eslint –fix”, “git add”] }}当文件变化，我们git commit它们，pre-commit钩子会启动，执行lint-staged命令，我们对于lint-staged如上文配置，对本次被commited中的所有.js文件，执行eslint –fix命令和git add,命令，前者的的目的是格式化，后者是对格式化之后的代码重新提交。除了在package.json中配置，也可以在.lintstagedrc、lint-staged.config.js文件中，lint-staged的常用选项除了liners之外，还有ignore、concurrent 等，具体参考文档：{ “lint-staged”: { “linters”: { “.{js,scss}”: [“some command”, “git add”] }, “ignore”: ["/dist/.min.js"] }}对于文件的过滤，lint-staged的格式如下：{ // .js files anywhere in the project “.js”: “eslint”, // .js files anywhere in the project “/.js”: “eslint”, // .js file in the src directory “src/.js”: “eslint”, // .js file anywhere within and below the src directory “src/**/*.js”: “eslint”,}lint-staged提供的功能远不止于此，它只是平台，具体的格式化工具的搭配有很多，如对于图片的、样式的、.tsx、.md等文件的。 ...

在有了Husky赋能之后，我们有能力在Git的钩子里做一些事情，首先不得不提的是代码的提交规范和规范的校验，优雅的提交，方便团队协作和快速定位问题。首推Commitlint，另外@加神 推荐了Gitmoji也是一个很有意思的工具。安装npm install –save-dev @commitlint/config-conventional @commitlint/cli// 生成配置文件commitlint.config.js，当然也可以是 .commitlintrc.jsecho “module.exports = {extends: [’@commitlint/config-conventional’]};” > commitlint.config.js配置在husky的配置加入CommitlIint配置，v1.0.1版本以后为HUSKY_GIT_PARAMS，v0.14.3为GIT_PARAMS"husky": { “hooks”: { “pre-commit”: “npm run test”, “commit-msg”: “commitlint -e $HUSKY_GIT_PARAMS” } },定制提交规范提交格式（注意冒号后面有空格）<type>: <subject>常用的type类别upd：更新某功能（不是 feat, 不是 fix）feat：新功能（feature）fix：修补bugdocs：文档（documentation）style： 格式（不影响代码运行的变动）refactor：重构（即不是新增功能，也不是修改bug的代码变动）test：增加测试chore：构建过程或辅助工具的变动例子：git commit -m ‘feat: 增加 xxx 功能’git commit -m ‘bug: 修复 xxx 功能’subjectsubject是 commit 目的的简短描述，可以做一些配置，如最大长度限制。commitlint.config.js文件配置rule配置说明:：rule由name和配置数组组成，如：’name:[0, ‘always’, 72]’，数组中第一位为level，可选0,1,2，0为disable，1为warning，2为error，第二位为应用与否，可选always|never，第三位该rule的值。具体配置例子如下：module.exports = { extends: [ “@commitlint/config-conventional” ], rules: { ’type-enum’: [2, ‘always’, [ ‘upd’, ‘feat’, ‘fix’, ‘refactor’, ‘docs’, ‘chore’, ‘style’, ‘revert’ ]], ’type-case’: [0], ’type-empty’: [0], ‘scope-empty’: [0], ‘scope-case’: [0], ‘subject-full-stop’: [0, ’never’], ‘subject-case’: [0, ’never’], ‘header-max-length’: [0, ‘always’, 72] }};这里列出了大部分常用的配置，其它的可以参考Commitlint网站，具体使用例子：这里我们使用错误的提交方式，最上面的是自动测试的脚本，大家可以忽略，husky给出了commit-msg的input为xxx，触发了subject-empty，type-empty两个规则，提交不符合规范，被拦了下来。如果是正确的提交，例子如下：关于Commitlint的使用就到这里了。 ...