你值得拥有的详细前端工做流讲述(eslint, commitlint, prettier, husky, stylelintrc, tsconfig...)

前言

前端工程流配置是前端工程师想要独当一面必须掌握的一项技能，这一篇详细讲述若是一个项目从0开始搭建，会涉及到哪些规范，如何使用，配置，以及遇到的问题。总结不易，以为有帮助能够点赞，收藏。为了方便下面内容的讲解，我用create-react-app建立一个项目json-react-template。

这里需注意一点，create-react-app建立项目时候，已经帮你git init。本身写脚手架的时候也能够添加这个功能

eslint

说到工做流不得不提eslint，它是用来检查js/ts代码规范的一个插件。可以帮助咱们写出更优雅的代码，可是不少人在使用eslint时候，每每会遇到一些问题，最大的问题就是eslint不生效，下面咱们具体来操做一下。

引入eslint

在这里咱们须要作三件事

1：编辑器（个人是vs code）须要安装eslint插件

2：安装eslint包

3：引入.eslintrc文件

前两步比较简单，正常操做，下面主要说说.eslintrc。不少状况下咱们不可能记住这么多规则，基本上到这里都是从网上复制一份过来。可是有时候就算是从网上copy可能也须要花费一些时间，主要是网上文章太多，选择的时候容易对咱们形成干扰。这里我说一个我本身以为比较优雅的方式，在咱们的github上面，有一个git gists。这个是github提供给咱们的一个功能，可以让咱们保留一些代码片断，因此咱们就能够事先找到一份.eslintrc配置放到上面，方便后面查找（这样从此就能够直接去gist复制了，方向明确）。写到这里，我已经把以前保存的.eslintrc复制到项目里了。

eslint不生效

有了上面的配置，如今咱们来讲说eslint不生效状况，遇到这种状况咱们该怎么办呢？通常三步走。

1：检查vs code是否安装了eslint插件

2：检查.eslintrc规则是否正确或者相关插件是否安装

3：重启下编辑器

步骤1和步骤3很简单一笔带过，下面咱们来讲一下步骤2。基本上不少eslint失效的状况都是步骤2形成的。由于咱们是复制过来的规则，会致使有的插件没有安装或者因为eslint版本缘由致使规则写法改变（网上找的规则是eslint低版本的，可是你如今的项目是高版本）。拿我刚刚的项目举例，如今个人vs code检查已经失效了。

那如何检查上面所说的第二步是否有问题呢？很简单，执行一下eslint 让他去检查任意一个文件，这样就会暴露出问题。我主要以局部安装来讲明，执行如下命令。

./node_modules/eslint/bin/eslint.js ./src/App.js

咱们能够看到报错说没有找到‘airbnb-base’。查阅了一下其实对应的插件是eslint-config-airbnb-base，因此这里的问题就是没有安装相关插件。我本身先安装完，继续执行上面的命令，又报错以下。

继续报错显示allowAfterThis这条命令不合法，说明这个eslint规则，在高版本里写法已经改变了，我先直接把这个规则注释掉，从新执行了一下命令。 发现eslint已经生效了，vs code开始显示错误，最后咱们只要按照对应规则去更改便可。

.eslintignore

如今再来讲说.eslintignore，这个文件我以为必定是要的。由于在打包的时候能够减小打包速度，具体能够看看我以前写的这篇前端优化详解以及须要关注的几个问题。写.eslintignore须要注意一点,也是不少人写完不生效的缘由。.eslintignore的路径前缀是/或者不写，但不要写./以下。

// .eslintignore
./src/__test__/*.js // 错误写法 // 正确写法 /src/__test__/*.js 或者src/__test__/*.js 复制代码

.stylelintrc/.stylelintignore

这两个咱们就一笔带过，和eslint几乎是同样的，若是stylelint失效，请参考eslint方法解决问题。

tslint

tslint是用来检查ts语法规范的插件，可是因为tslint官方声明已经不在维护了，而且推荐用eslint来检查ts/tsx文件，因此从此使用eslint便可。那怎么作呢？很简单，只须要安装一些能检查ts的插件便可。更改一下.eslintrc配置(检查ts的版本) 复制规则以后，若是失效，直接按照上面eslint的作法在来一遍便可。

tsconfig.json

此次来讲说tsconfig.json,它的配置有不少，具体能够看看官网www.tslang.cn/docs/handbo… 接下来选几个项目中用到的属性进行说明，加深一下印象。

• module

说明：这个字段表示ts编译后，模块是以哪一种模块系统存在的，主要有如下几个'commonjs' | 'amd' | 'system' | 'umd' | 'es6' | 'es2015' | 'esnext'，咱们用commonjs/es6举例，源码以下

export const test = (value: number) => {
    console.log(value);
};
复制代码

// commonjs编译以下

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.test = void 0;
const test = (value) => {
    console.log(value);
};
exports.test = test;
复制代码

// es6编译以下

export const test = (value) => {
    console.log(value);
};
复制代码

• target

说明：这个字段表示把ts编译成什么样的目标代码es5仍是es6亦或是esnext。这个字段你们应该常常用到就不演示了。

• lib

说明：这个字段表示须要引入什么库，默认不写lib字段是引入dom库，引入dom库是什么意思？用直白的话说就是能够用document这些全局的dom变量，若是你写了lib可是没有依赖dom，使用document的时候就会报错，以下。

• allowJs/checkJs

说明：allowJs这个字段意思是否容许在ts文件里面引入js文件，checkJs表示是否检查js错误。

• jsx

这个主要表示将.jsx文件编译成什么形式，有三种形式'preserve', 'react-native', or 'react'。在react的项目里面直接设置成react就行。

• noImplicitAny

说明：这个表示当一个变量是隐式any类型的时候是否抛错，注意这里是隐式，不是你设置成any的。话说不清楚，直接看图。

• moduleResolution

说明：这个表示ts会以哪一种规则去引入文件，有两种模式'node' | 'classic'，通常选择node模式，具体规则看这个连接。

• include/exclude

这两个字段颇有用，一个是限制ts做用的范围，一个是排除特殊文件，好比咱们想要编译src下面全部ts/tsx文件，可是又不想编译测试文件怎么办，能够以下配置。

{
"include": [
        "src/**/*.ts",
        "src/**/*.tsx"
    ],
    "exclude": [
        "src/**/*.test.tsx"
    ]
}
复制代码

• sourceMap

生成相应的.map文件用于调试

• rootDir

编译以后文件存放的目录

• declaration

自动生成相应的 '.d.ts' 文件

还有不少字段不一一列举了，提供一个咱们常常用到的tsconfig配置，有详细的注释哦！

问题

经过create-react-app建立的项目，就算使用上面的tsconfig配置，仍是会出现一个'./logo.svg'找不到的问题。这个主要是ts没法识别这样的模块，因此就须要咱们本身去定义module了，格式以下。

declare module '*.svg';
复制代码

须要注意的是这些代码是要写到.d.ts文件里面。那如何让.d.ts生效呢？大体以下，咱们能够在tsconfig.json同级目录下创建types文件夹，在该文件夹下建一个名为index.d.ts的文件写入上面代码便可，.d.ts也是一个ts文件，因此也须要编译才行，此时可使用include字段，以下

"include": [
        "src/**/*.ts",
        "src/**/*.tsx",
        "types"
    ],
复制代码

commitlint

commitlint以前关注的比较少一点，可是随着工做年限的增加，愈来愈多的项目有commit提交规范，因此了解他是颇有必要的。我以为如今的commit提交信息能够分为两大类，一个是angular标准规范，这种规范适用于xx库和xx插件的开发，方便生成CHANGELOG.md。另外一种就是本身写提交规范，适用于本身公司的项目。下面按照两种规范一一说明。

angular提交规范

无论是标准仍是非标准，提交了commit以后，都须要作相应的检查，对于angular规范来讲有专门的配套插件帮你，它就是commitlint。咱们能够跟着安装下。这里注意咱们须要安装@commitlint/config-conventional和@commitlint/cli这两个插件，安装成功以后咱们应该如何去使用呢？这个时候就须要用到husky,husky插件能够帮咱们接管git hooks，从而在相应的阶段作出正确的处理。在package.json配置以下

"husky": {
     "hooks": {
           "commint-msg": "commitlint -E HUSKY_GIT_PARAMS"
     }
}
复制代码

疑惑

1：若是按照上面的写法，husky必须是低版本，个人是4.3.8。网上的文章不少都是这种写法，可是当我操做的时候，husky已经到了7.x版本，结果发现commtlint失效，因此若是你想要上面的配置生效，能够和我同样下载4.3.8，那若是非要高版本了？先等等，下面内容会说道。

2：看到上面配置你可能会蒙，-E是什么意思，其余字母行么？先不要慌，从此遇到这种，咱们不要多想这确定是插件自带的参数，因此只须要执行--help,就能够看到其内容，以下 能够看到-E就是"check message in the file at path given by environment variable value",翻译出来就是“在给定的环境路径下，检查信息”，然后面HUSKY_GIT_PARAMS就能够告诉husky 是检查哪个hooks路径。

3：咱们一直说commintlint，可是为何插件安装的是@commitlint/cli。咱们在npm上翻一下就知道，其实@commitlint/cli就是commitlint的别名，安装@commitlint/cli就行，别纠结。

4：那为何还要安装@commitlint/config-conventional，由于commintlint只是来检查规范的，可是具体用哪一种规范你也要定义好。就像eslint是检查规范工具，可是咱们也要继承airbnb这个规则了。咱们就把@commitlint/config-conventional看成airbnb便可。

5：因此你把husky版本下降你还会遇到报错，由于你没有指定commitlint.config.js。他是为了告诉commitlint须要继承哪一种规范，配置以下

module.exports = {
    extends: [
        '@commitlint/config-conventional'
    ]
};
复制代码

6：如今提交代码时候，就能够看到错误了，以下

angular规范写法

上面一系列的配置，可让你在提交代码时候，进行commit规范检查，这个时候咱们就要按照正确的规范提交了。那怎么样才算一个正确的规范了，网上有不少文章，这里我不说的太复杂，说的太复杂的反而让人不了解，具体能够看看官网连接。大体规范以下。

<type>(<scope>): <subject>

// 空一行

<body>

// 空一行

<footer>
复制代码

1：header部分最重要分为type,scope,subject

type：build|ci|docs|feat|fix|perf|refactor|test

scope：表示改动的文件范围，就是写一下改了哪里的模块便可。

subject：对此次改动的具体描述，如改了什么bug或者增长了什么需求。

！！！注意：这里必定要注意"feat(package.json): 增长了commintlint功能"。冒号后面必定要有一个空格哇！

2：body部分就是写一下更详细的描述，这个是可选的。

3：footer部分表示若是你的改动是破坏性的好比你写的是插件，大版本升级把api都改了。须要在这里进行详细描述包括迁移说明。

commitizen/cz-conventional-changelog

有的人若是记不住angular书写规范，能够安装这两个插件，这两个插件就是在你提交代码时候自动帮你组织commit信息，不用你本身想，可是我以为本身手写更快点。cz-conventional-changelog这个和airbnb同样，是和commitizen配套使用的。

1：他们两个也有一个config配置文件，只不过咱们是写在package.json里面，以下

"config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
复制代码

2：第二个问题因为咱们都是局部安装的，因此不能全局使用git cz。这个时候咱们能够写一个script命令来解决，提交时候就再也不是git commit而是npm run commit可能感受粗糙了点。以下

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "commit": "git-cz"
  },
复制代码

到这里一个符合angular标准的提交规范就配置好了。

本身的commmit标准

但若是咱们就不想用angular规范该怎么办呢？有人会说能够设置本身的commintlint.config.js。能够是能够不过总以为在他的限制范围内，我想本身获取到提交信息，而后根据提交的信息，用正则或者其余规则判断，从而给出对应的规范能够么？确定是能够的。假如如今咱们作了一个产品叫xx商城，项目名为json-shopping。这个项目中的bug和需求都有一个编号，因此咱们想要的提交规范就是"[json-shopping-123]: 修复了xxbug"。不知足这种规范统一报错。那么咱们该怎么作呢？咱们参考一下vue的作法具体以下。

1：将commit-msg配置成本身的脚本

"hooks": {
      "commit-msg": "node scripts/verify-commit-msg.js"
 }
复制代码

2：创建scripts文件夹，编写verify-commit-msg.js脚本以下

const chalk = require('chalk');
const msgPath = process.env.HUSKY_GIT_PARAMS || '.git/COMMIT_EDITMSG';  // 注意由于用的是husky因此这里是HUSKY_GIT_PARAMS
const msg = require('fs').readFileSync(msgPath, 'utf-8').trim();
const commitRE = /^\[json-shopping-\d+\]\:\s.{1,50}/;

if (!commitRE.test(msg)) {
  console.log();
  console.error(
    chalk.red(` 提交信息不知足项目要求，具体以下\n`) +
    chalk.red(` [json-shopping-xxx]: 修复xxxbug\n`) + 
    chalk.red(` 或者\n`) + 
    chalk.red(` [json-shopping-xxx]: 完成xxx需求\n`)
  )
  process.exit(1)
}
复制代码

展现结果以下

husky

写到这里原本不想折腾了，husky4.x版本其实已经够用。可是无奈版本升级改动太大，本着写文章是为了让本身加深印象的原则，咱们继续来讲husky高版本。husky的做用就不说了，配合hooks能够帮咱们作许多事情。常见的hooks有pre-commit，commint-msg，pre-push。若是想知道更多hooks做用能够查看这篇文章。好了话很少说，我先把husky升级一下。emmmmmmmm...升级完果真commitlint失效了。

生成.husky

高版本的husky是须要你使用.husky下面的hooks脚本，不会在本身调用.git hooks脚本，生成.husky脚本很简单。执行命令husky install便可。可是因为husky是局部安装的，因此通常都是写一个script命令，而后执行npm run prepare以下。

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "prepare": "husky install"
  },
复制代码

如今咱们先按照husky官网生成一个hooks脚本，执行命令"npx husky add .husky/pre-commit "npm test""。截图看一下 咱们发现生成了pre-commit文件，而且开头是". " $(dirname "$0")/_/husky.sh""。说明咱们定义hooks脚本时候，须要在开头带上这句话，至于_文件夹下面的这个husky.sh文件是作什么的，具体看这篇文章。

实现commitlint

如今咱们知道了高版本的husky是须要本身在.husky文件夹下写一个脚本才会生效，那么按照上面的例子，我写了以下commit-msg脚本。

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

commitlint -E HUSKY_GIT_PARAMS
复制代码

1：可是git commit以后发现没有生效，缘由是这个脚本是不可执行的，执行以下操做chmod ug+x .husky/*,给脚本添加执行权限。

2：继续git commit仍是有问题，由于commitlint不是全局的而且已经没有HUSKY_GIT_PARAMS这个写法了，须要替换成$1。因此最终改为以下。

#!/bin/sh
. "$(dirname "$0")/_/husky. npx commitlint -e $1 复制代码

3：若是想换成本身的commit规范，写法以下

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

node ./scripts/verify-commit-msg.js
复制代码

lint-stage

在前端工程里面，我以为检查有4个方面

1：vs code编辑器检查

2：webpack编译检查

3：git commit提交检查

4：CI/CD部署检查

只有作了这四个方面的检查，我以为才是比较全的，今天咱们介绍的是vs code和git commit。可是git commit以后，正常状况下若是这么设置"pre-commit: eslint src/*.js",检查的是所有文件，有点浪费性能。因此出现了lint-staged，他只会检查咱们提交的文件，大大提升了性能，那该如何去作呢？以下

配置husky(7版本)

.husky/pre-commit

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged
复制代码

配置.lintstagedrc

{
  "*.js": [
      "eslint --fix"
  ],
  "*.(css|less)": [
      "stylelint --fix"
  ]
}
复制代码

固然前提都是要先安装插件lint-staged。

jest.config.js

一个完整的项目jest是必不可少的，配置jest也是典型几步，咱们按照项目是react框架来举例。

1：安装jest enzyme @testing-library/react-hooks(测试hooks)插件

2：配置jest.config.js以下

module.exports = {
    roots: ['<rootDir>/src'],
    setupFiles: [],
    clearMocks: true,
    collectCoverage: true,
    transform: {
        '^.+\\.tsx?$': 'ts-jest'
    },
    // 1：解决Jest: a transform must export a `process` or `processAsync` function.
    moduleNameMapper: {
        '^.+\\.(css|less)$': './jest/style.transform.js'
    },
    transformIgnorePatterns: ['\\\\node_modules\\\\'],
    globals: {
        'ts-jest': {
            tsConfig: './tsconfig.json'
        }
    },
    testRegex: '(/__tests__/.*|(\\.|/)(test|spec))\\.tsx?$',
    moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node']
};
复制代码

3：按照以上配置可能会出现一个"a transform must export a process or processAsync function."报错，解决方法以下。建立一个jest文件夹，在该文件夹下面建立style.transform.js，内容以下

module.export = {
    process() {
        return '';
    }
};
复制代码

跑测试用例的时候能够直接写script命令而后执行，可是这里推荐一下咱们的作法，咱们的项目是在提交以前跑测试用例，那么该怎么作呢？用husky高版本举例。在.husky文件夹下面建立pre-push脚本并添加执行权限，内容以下

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm run test
复制代码

而后在编写script命令

"scripts": {
    "test": "jest"
  },
复制代码

prettier

这个配置，主要是用来格式化代码，这里有一个疑问，如今已经有eslint帮咱们规范格式了，为何还要用prettier了，我以为多是由于有的格式问题无法自动fix，并且就算自动fix那也只能在git commit的时候。对于强迫症来讲，从百度搜索复制一份代码过来，看着不少警告不及时处理有点受不了。若是添加了prettier就能够在保存的时候自动格式化。那么如何去作呢？以下

1：安装vs code插件prettier

2：安装prettier依赖包

3：配置.prettierrc

{
    "trailingComma": "es5",
    "tabWidth": 4,
    "semi": true,
    "singleQuote": true,
    "bracketSpacing": false,
    "arrowParens": "avoid"
}
复制代码

4：在vs code中的setting里面设置，保存以后自动格式化

conventional-changelog

这是最后一个配置了，主要和angular规范一块儿使用生成CHANGELOG.md。首先安装conventional-changelog-cli依赖包，而后添加一个script命令便可 以下

"scripts": {
    "changelog": "conventional-changelog-cli -p angular -i CHANGELOG.md -s -r 0"
  },
复制代码

最后

为何要写这一篇文章，一是为了巩固本身的知识，让本身有能力作一个从0搭建一个完整的项目。虽然这只是第一步规范，可是却很重要，第二个缘由是我能够储备一个react模版，这样下次再遇到react项目，就能够直接去个人github克隆下来，快速使用。模版已经上传，你们能够fork,在实际的项目使用中发现问题，而且提出意见，最后用一个效果图结束这篇文章。

参考文章

tsconfig经常使用配置解析 husky6版本+commitlint使用与脚本全面分析（husky v4升级v6变化巨大）