背景多人在做一个项目时，总是因为大家的代码风格不统一，需要通过文档约定来统一风格。比如文件的命名方式，有的人首字母大写，有的人首字母小写，在js、ts、vue中都有这样不同的风格。针对这种情况，我们创建了一个约定文件来规定文件夹的命名方式，但是这样做有一个缺点就是不能从根本上解决，就是新同事可能不知道这个规则，然后再创建一个新的一。一个非常规的文件名。除了文件名，投稿规范也大不相同。有些人在提交时不添加类型。我们还为此创建了一个公约文件。慢慢在文件目录下加一个docs文档固然有好处，但不能从根源上限制问题。所以现在的前端项目引入了工作流的概念，也有很多自定义工作流的辅助工具。工作流程概述多人项目总是需要指定一些规范，以使代码风格尽可能统一。我们需要用到以下工具：代码美化-prettier语法规范-airbnb语法校验-eslintgit-hook-husky提交规范-commitlint文件命名规范-ls-lint自动代码修复-lint-stagedeslint&prettier这里写了一篇文章对比好文章，这里就不展开如何配置了。commitlint代码提交规范commitlint用于帮助团队遵守提交规范，更多信息可以参考官网安装npminstall--save-dev@commitlint/config-conventional@commitlint/cliformat[type]:[subject]type是以下字段feat:Newfunction（特性）fix:Fixbugdocs:Documentation（文档）style:format（不影响代码运行的变化）refactor:重构（即不属于新特性或代码变化的代码变化）bugs)test:增加testchore:构建流程或辅助工具的变更upd:更新功能模块workflow:Workflow变更以描述内容为准，比如修复设备日志中颜色值转换问题的完整描述，??注意即冒号后有空格，如gitcommit-m'fix:Fixdevicelogcolorvalueconversion问题'gitcommit-m'chore:修改commitlint配置文件'commitlint.config.jscommitlint支持终端输入命令的形式进行验证，当然也支持配置文件的形式。配置文件的具体内容如下：rulers字段由名称和配置数组组成。配置数组包括：Level[0,1,2]：0表示规则被禁用，1会被视为警告，2会抛出异常Applicablealways|never：是否应用规则Value：改变规则要应用的值。配置数组可以是：一个数组，一个返回数组的函数，或者一个返回数组的promise。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,'总是',72],},};配置git-hookGithook其实就是你在git运行过程中的回调。这里我们只关心一个git-hook，也就是pre-commit，提交前的回调。配置好commitlint之后，我们就配置好了提交规范，但是我们遇到了一个问题，什么时候应该校验提交规范。我们从commitlint官网了解到，需要安装husky，通过简单配置即可执行Githook。husky&yorkie帮助我们直接在package.json中配置git-hook.husky。package.json中husky配置的内容如下："husky":{"hooks":{'commit-msg':'commitlint-EHUSKY_GIT_PARAMS',}}if我们通过vue的脚手架搭建项目（vue-cli).事实上，yorkie是内部使用的。yorkie是优雨熙forkhusky后的小改款。所以此时可以在package.json中配置"gitHooks":{"commit-msg":"commitlint-e$GIT_PARAMS"}，注意两次配置传递给-e的参数是不同的，一个是HUSKY_GIT_PARAMS和另一个是GIT_PARAMS。其实husky以前是GIT_PARAMS，升级到v1.0.1后变成了HUSKY_GIT_PARAMS。Lint-staged有一个提交github。是不是也可以做一些代码格式美化，修复eslint问题？lint-staged就是为了这个。使用lint-staged工具识别添加到stage区的文件，即每次只扫描当前修改的文件，即只扫描gitadd添加到stage区的文件，完成增量代码检查.安装lint-stagednpmi-Dlint-stagedlint-staged配置如下："lint-staged":{"*.{js,jsx,vue,ts,tsx}":["vue-cli-servicelint","gitadd"]}ls-lint在较大的项目中，我们需要约定文件的命名格式规范。如下：1.文件夹&文件使用驼峰命名法（小驼峰），例如：文本文件夹./layout/...文件名iiapHeader.vuels-lint帮我们自动校验文件命名约定，省去约定的麻烦，我们只提交时需要检查文件的命名规范，在npm中添加如下命令"scripts":{"ls-lint":"ls-lint"}，.ls-lint.yml文件配置如下：ls:.vue:PascalCase.js:kebab-case.config.js:小写.ts:camelCase|PascalCase.d.ts:驼峰式|烤肉串.spec.ts:camelCase|js:kebab-case.spec.js:kebab-caseignore:-dist-test-.babelrc.js-.eslintrc.js-.prettierrc-.github-.git-node_modules完整的配置所以我们整个工作流程整合：代码风格统一->eslint优化->文件命名约定->提交规范我们创建：.ls-lint.ymlcommitlint.config.jspackage.json配置："scripts":{"ls-lint":"ls-lint"},"gitHooks":{"pre-commit":"ls-lint&&lint-staged","commit-msg":"commitlint-e$HUSKY_GIT_PARAMS"},"lint-staged":{"*.{js,jsx,vue,ts,tsx}":["vue-cli-servicelint","gitadd"]}
