构建可靠的前端项目 - 少不了这些必备工具集

构建可靠的前端项目少不了这些必备工具集： ESLint、Prettier、Editorconfig、Husky、lint-staged、commitlint，它能帮助我们约束编码风格与提及规范，下文介绍这些工具集的使用，文末提供一些可参考的项目。,ESLint 是 JavaScript/TypeScript 编程中一个最受欢迎的代码规范检查工具，可避免一些由于低级的代码错误而导致的项目崩溃，另一方面也能规范我们的编码习惯。,为项目开发时依赖添加 eslint 插件 npm i eslint -D，紧接着我们需要设置一个配置文件，如果没有全局安装 eslint 插件，可能就需要这样去做 ./node_modules/.bin/eslint --init，我不喜欢这样，好在还有 npx 这个工具，我们可以这样做 npx eslint --init。,执行 --init 命令后，可以选择使用的框架、模块类型、语言（JS/TS）等，随后会生成一个 .eslint{yml|js|json} 文件。,ESLint 支持 JavaScript、JSON 或者 YAML 等多种文件格式，这里使用的是 YAML 格式，相比于 JSON 可以写一些注释。,对上述文件几个配置做一些简单介绍：,jsx：启用 JSX,ecmaFeatures：想使用的额外的语言特性,有了以上配置后，就可以执行 npx eslint ./your_file_or_directory 命令检测指定的文件或目录。,在项目根目录创建 .eslintignore 文件告诉 ESLint 忽略掉某些特定的文件或目录。忽略模式可以参照 .gitignore 规范[2]。,怎么设计一套好的编码规范呢？也无需重头造轮子，借助一些社区开源的编码规范最佳实践，可以直接引入在我们的项目中，再根据自己的需求做一些定制。,我们这里以 Airbnb 为基础，做一些自定义的修改，参考 Airbnb JavaScript 风格指南[3]。,安装 eslint-config-airbnb[4] npm i eslint-config-airbnb -D，如果你不需要 React，可以参考 eslint-config-airbnb-base[5] 这个包，在 Node.js 服务端可以使用这个包。之后添加 "extends": "airbnb" 到你的 .eslintrc 文件。,每改动代码都运行 npx eslint ./ 命令执行代码检测，效率还是有点低效的，我们希望改动代码后，IDE 能够给我们自动提醒格式错误的代码片段。,在 VS Code 中，需要在应用商店安装 ESLint 插件。,图片,当我没有遵守 ESLint 规范去修改代码后，编辑器会及时给我们一些错误提示。,图片,**在使用 ESLint 时，另一个被搭配使用的工具是 ****Prettier**[6]，这是一个专业的代码格式化工具，支持 JS、TS、HTML、CSS 等众多语言 。,开发时依赖安装 Prettier，并创建一个空的配置文件，让编辑器和其它工具知道正在使用 Prettier。,创建 .prettierignore 文件，让编辑器和 Prettier CLI 知道哪些文件不需要格式化，它建立在 .gitignore .eslintignore 之上。,命令行执行 **npx prettier --write .** 手动触发，对于一个大项目来说可能会花费一些时间，因此还可以指定目录或文件来格式化。,ESLint 提供了 eslint --fix 命令用来自动修复代码格式问题，为什么还要用 Prettier 呢？,如果我说在代码格式化方面 Prettier 比 ESLint 更专业，你可能也不会信服，毕竟没有证据来证明这一点。下面我将通过一个例子来验证。,下面这段 JavaScript 代码片段，存在两个问题，一个是 console.log(...args) 没有缩进，另外一个是 createData()  这一行超出了最大长度限制。,调整 ESLint 行的最大长度限制。,随后控制台执行 eslint --fix 自动修复命令，发现虽然 console.log(...args) 这个缩进问题解决了，但是行的最大长度限制  max-len 还是未能解决。,图片,接下来看看 Prettier 的效果如何呢，修改配置文件同 ESLint 保持一致。,运行 prettier --write 命令后，它格式化了我们的代码，结果是我们预期的。,图片,ESLint 与 Prettier 之间存在交集部分，一起使用就少不了冲突。例如，我的 ESLint 配置规则继承了 airbnb，而 airbnb 字符串默认使用单引号，而 Prettier 字符串默认使用双引号。,在第一次执行 eslint --fix 格式化后的 str 为 const str = '编程界'; 帮我修复了这个格式问题，但是又运行了 Prettier 格式化后，ESLint 提示我们错误又出现了，这样就陷入了一个死循环。,图片,正所谓术业有专攻，我们让 ESLint 专注于代码质量检测工作，Prettier 负责代码的格式化工作。,解决方案第一步：开发时依赖安装 eslint-config-prettier **npm i eslint-config-prettier -D** 插件，目的是禁用掉 ESLint 插件与 Prettier 之间冲突的规则。,解决方案第二步：赋予 eslint --fix 以 Prettier 规则格式化代码的能力，并以 ESLint 的方式报告错误。开发时依赖安装 eslint-plugin-prettier[7] npm i eslint-plugin-prettier -D 插件，按照以下规则配置。,上面的两步操作也可以写为一步，也是官方推荐的一个 https://github.com/prettier/eslint-plugin-prettier#recommended-configuration[8],当把 prettier 结合到 eslint 里时，usePrettierrc 这个参数表示是否使用 .prettierrc 文件中配置信息，默认是启用的，无需配置。,prettier 规则默认箭头函数如果只有一个参数也要加上 ()，我想去掉这个规则，发现这个配置在 VSCode 展示有点问题无法读取到修改后的 arrowParens 这个配置（其它配置例如  singleQuote，在 IDE 中是生效的）， 编辑器会提示错误，但 eslint --fix 时没有问题（此时证明 配置没问题，手动执行 eslint 还是生效的）。,图片,没有好的解决方案，为了让 IDE 不报错，首先尝试在 ESLint 配置里加上 arrowParens 这个配置，发现问题解决了，但是这样 ESLint prettier 配置中、.prettierrc 要写两遍总归不是太好。,另外一种是不在 ESLint 配置里加上 arrowParens 这个配置，编辑器关闭重新打开也是没问题的，反复的试验了下，发现改完 .prettierrc 这个配置文件，VS Code 编辑器提示不会立即生效还默认是打开前的配置，如果有遇到类似问题，可以尝试关闭下再打开看看。,Editorconfig[9] 是用来维护不同编辑器之间代码风格，通过配置文件 .editorconfig 设置，该配置文件的优先级会更高，会覆盖任一编辑器的配置。,团队中既然制定了规则，大家就要共同遵守，如果不加以限制，别人改动代码后不做 ESLint 检查，或者提交代码忘记执行代码检查命令，就会导致未经检测的代码被提交进项目仓库，代码规则的制定也就形同虚设了。,使用 git 版本控制的项目中，默认都有一个 .git/hooks 目录，包含了 git 在 commit、push 时的一些 hooks 脚本，结合这些可以做一些代码的校验操作。,使用 husky 工具，可以将 git hooks 的使用变得更加简单，同时也能解决，.git 目录提交无法跟踪的问题。,在 husky 最新版本中，会生成一个 .husky/ 目录，以往的版本中是在 package.json 中配置一个 { "husky": {"hooks": {} } } 实现的。,Husky 推荐在 package.json 的 scripts 里设置 prepare，因为在执行 npm install 命令时，将会自动执行 prepare 脚本。,注意在 npm version < 7 时 npm set-script 命令不支持，需要手动在 package.json 设置 { "scripts": { "prepare": "husky install" } } 或升级 Node.js 版本为 v16.x LTS。,添加一个 hook，在 git commit 前执行 eslint 命令检测代码规范。,现在执行 git commit 命令如果存在不规范的代码，本次 commit 就会被拦截。,图片,如果本次我只修改了 src/index.tsx 这个文件，由于历史原因最开始没有加 ESLint 规范，之前的一些未修改的文件也被检查了，当看到成百上千条 ESLint 报错提示，是不是会出现想收回使用 ESLint 工具的想法？这种问题在团队开发中，如果一开始没有设定代码规范，后期加入代码规范时，这种问题还是会常见的，解决方案继续往下看。,每次只对修改的文件做检查，就要用到 **lint-staged**[10] 这个工具了，解决老项目的历史包袱问题。,lint-staged 是对 git add 进入暂存区的文件进行检查，开发时依赖安装 npm i lint-staged -D，修改 package.json 文件。,注意，**npx eslint --fix**** 后不要指定路径，例如 **npx eslint --fix ./src/** 会出现只修改了 A 文件，但是其它有问题的 B、C 等文件也被检测了**。,修改 .husky 目录下的 pre-commit 文件。执行的流程是：,关于 commit 如果没有进行规范，最终每个人写出来的风格也是不一样的，所以这个还得借助于工具，帮助我们规范提交的习惯。,分享两个 git commit message 的讨论：Stackoverflow - Git Commit Messages: 50/72 Formatting[11]、知乎 - 如何写好 Git commit log?[12],安装 commitlint cli 和提交信息校验规则 @commitlint/config-conventional[13]，详细的参考文档 commitlint.js.org[14]。,使用格式 git commit -m '<type>[Optional scope]: <description>'，介绍一下 type 属性的几种类型约束。,如果我这样 git commit -m '添加 commitlint 工具' 提交代码，就会收到以下错误提示。,图片,正确的做法是加上类型信息 git commit -m 'feat: 添加 commitlint 工具'。,使用 commitlint 每次都需要输入类型，需要我们记住这些规范，于是就有了 [commitizen](https://github.com/commitizen/cz-cli "commitizen")。,全局安装 npm install -g commitizen，之后可以使用 git cz 替代 git commit 命令。还需要为 commitizen 指定一个 Adapter，例如 cz-conventional-changelog[15] 基于 commit message 的轻量级约定，提供了一组简单的规则来创建明确的提交历史，参考 约定式提交[16]。,执行以上命令后，在 package.json 中会生成如下配置,对文件做一些任意修改，执行 git cz 命令后，运行效果如下所示：,图片,当选择一个类型后，终端会出现一个交互式的操作，包括：影响范围、简短的变更描述（必须）、详细的变更描述、是否存在不兼容的变更、是否影响某些打开的 Issues，这个里面只有简短的变更描述是必填的。,图片,commit message 成功后，执行 git log 看到的日志是这样子的。,图片,如果想自定义 Adapter 而不是使用 cz-conventional-changelog，推荐看下 cz-customizable[17] 这个开源项目，这里不再过多描述。,结合 standard-version[18] 实现自动生成  CHANGELOG。,以上介绍内容，实际应用可参考这个前后端项目 https://github.com/qufei1993/compressor[19]，不同的是该项目是基于 TypeScript 编写，正好也可以学习下。,[1]ESLint 官网 Rules: https://cn.eslint.org/docs/rules/,[2].gitignore 规范: https://git-scm.com/docs/gitignore,[3]Airbnb JavaScript 风格指南: https://github.com/lin-123/javascript,[4]eslint-config-airbnb: https://www.npmjs.com/package/eslint-config-airbnb,[5]eslint-config-airbnb-base: https://www.npmjs.com/package/eslint-config-airbnb-base,[6]Prettier: https://prettier.io/,[7]eslint-plugin-prettier: https://github.com/prettier/eslint-plugin-prettier,[8]https://github.com/prettier/eslint-plugin-prettier#recommended-configuration: https://github.com/prettier/eslint-plugin-prettier#recommended-configuration,[9]Editorconfig: https://editorconfig.org/,[10]lint-staged: https://github.com/okonet/lint-staged,[11]Stackoverflow - Git Commit Messages: 50/72 Formatting: https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting,[12]知乎 - 如何写好 Git commit log?: https://www.zhihu.com/question/21209619/answer/257574960,[13]@commitlint/config-conventional: https://github.com/conventional-changelog/commitlint/tree/master/@commitlint/config-conventional,[14]commitlint.js.org: https://commitlint.js.org/,[15]cz-conventional-changelog: https://github.com/commitizen/cz-conventional-changelog,[16]约定式提交: https://www.conventionalcommits.org/zh-hans/v1.0.0/,[17]cz-customizable: https://github.com/leoforfree/cz-customizable,[18]standard-version: https://github.com/conventional-changelog/standard-version,[19]https://github.com/qufei1993/compressor: https://github.com/qufei1993/compressor