前端代码工作流

Posted 2021-05-12 在厕所喝茶

编辑器选择

在刚接触前端的时候，我使用的编辑器是sublime。主要特点是轻量，缺点就是安装插件的时候过程比较麻烦，而且代码提示做的也不够好；后来听说webstrom这个地表最强编辑器功能很强大，就尝试着使用这个编辑器。webstrom给我的感觉是就功能很强大，但是很臃肿，软件包很大。实际上我用到编辑器的功能就几个，但是webstrom给我提供了一大堆功能。主要还是webstrom这东西太吃内存了，电脑性能支撑不起来，所以后面使用了一段时间就放弃了；后来有同学给我推荐了vscode这个编辑器。发现这个编辑器也很轻量，而且提供了很多插件给你选择安装，最重要的是vscode是免费的（虽然sublime也是免费的），在后来的工作中，我一直都是使用vscode的。

代码规范

刚学前端的时候还有刚毕业出来的那一年，我其实是不怎么关注代码规范这方面的东西，基本都是代码写完了，然后在编辑器中来一个右键-格式化文档，遵循的原则就是能用能看就行了。其实中间有一段时间我是有尝试过去使用eslint这些代码规范化的工具的，但是那时候我就是个小白，eslint报错或者编辑器哪里提示格式不规范，我都是手动一个地方一个地方去修正的，连eslint --fix这些命令都不知道的，更别说集成到vscode当中了，后来就觉得太麻烦了，就没有在使用了，不过现在想想还是有点好笑，我居然会手动一个一个地方去修改那些代码不规范的问题。为什么这里要讲到代码规范呢？原因如下：

• 良好的代码规范可以减少bug的出现。比如，当初我遇见一个ie上的bug，就是使用element-ui的时候引入了2次Button组件，ie上面是不允许一个对象上面出现2个同名的key的，而且ie上面的报错提示并不是很容易让人找出是什么原因，也不能具体定位到那个文件的哪一行。后来我把ie上面的报错到百度上面一查才知道是ie不允许一个对象上面出现2个同命的key的，问题根源找到了，但是是在那个文件里面，需要一个一个去找，当时这个bug花了挺久的时间才解决了。现在想想，要是当初这个项目能有个eslint这些代码规范检查工具，这个bug应该就能很快被解决掉了。因为eslint的规则也是不允许对象上面有2个同命key的，并且还能提示是哪个文件出现同命key的
• git提交记录。有些代码比较乱，或者有些开发者喜欢使用右键-格式化代码，将代码格式化成自己想要的格式。这就会导致git的提交记录会被覆盖，后面再看代码就不能知道这些代码是干什么的了。打个比方，比如我在A文件的第10行修改了一个bug，提交代码的时候写修复了xxxbug。这里说一下，我们可以借助vscode的插件看见代码每一行的代码提交记录的。然后另一位开发者，把A文件拉下来，来了一个右键-格式化代码，第10行的代码被格式化了。这个时候另一位开发者把代码提交了，提交记录写的是新增xxx功能，这个时候整个文件的每一行提交记录都是新增xxx功能，实际上新增功能的代码就在一小段范围之内。这个时候如果其他开发者把A文件拉下来，根本就不知道第10行的代码是修复了bug，只看见了新增xxx功能，然后去找提交这个记录的开发者问第10行的代码是干什么用的，然后开发者就说，我没改过这里啊，我不知道啊。这样子下来，代码的提交记录就无迹可寻了，想找到当初提交代码的人问一下都不行了。
• 统一规范。不同开发者可能有不同的开发习惯，有的人喜欢使用var，有的人喜欢用const。这样就会导致代码的可观性非常差，一会一个样子，简直就是百花争鸣，百家齐放。

eslint

eslint是一个检查javascript代码规范的工具

• 安装并初始化
  这里安装是基于项目来安装的，并不是全局安装的，全局安装就会使项目环境依赖于全局环境了

npm i eslint -D

npx eslint --init

npx eslint --init 命令执行完后，就会在项目的根目录下生成eslint的配置文件

• 使用

忽略整个文件的检查,写在文件首行

/* eslint-disable */

文件开启或者禁用某些eslint规则，写在文件首行，多个使用逗号分隔

/* eslint no-console: "error" */

或者

/* eslint-disable no-debugger, no-console */

忽略某一行的检查

// eslint-disable-next-line

或者

/* eslint-disable no-debugger, no-console */
console.log('test')
/* eslint-enable no-alert, no-console */

或者

alert('test') // eslint-disable-line no-alert

• 命令

下面三个命令是比较常用的

检查src目录下任意目录下后缀名为js和vue的文件是否符合规范

eslint --ext .js,.vue ./src

修复src目录下js和vue文件不符合代码规范的地方，注意有些并不能自动修复的，需要手动修复的

eslint --fix --ext .js,.vue ./src

仅仅检查和修复改变过的文件

eslint --cache --fix --ext .js,.vue ./src

• 配置

module.exports = {
    // 环境
  env: {
    browser: true,
    es2021: true
  },
  // 识别webpack别名，需要安装eslint-import-resolver-webpack
  settings: {
    'import/resolver': {
      webpack: {
        config: './build/webpack.base.js'
      }
    }
  },
  // 拓展，需要安装 eslint-config-prettier，eslint-plugin-prettier，eslint-config-standard，@vue/eslint-config-standard
  extends: ['plugin:vue/essential', 'standard', 'plugin:prettier/recommended'],
  // 解析器配置选项
  parserOptions: {
    // 指定es版本
    ecmaVersion: 12,
    // 代码支持es6，使用module
    sourceType: 'module',
    // 解析器，需要安装babel-eslint
    parser: 'babel-eslint'
  },
  // 插件，需要安装eslint-plugin-vue
  plugins: ['vue'],
  // 规则
  rules: {
    'import/extensions': ['error', 'always'],
    'prefer-destructuring': 'off',
    'no-param-reassign': 'off',
    'no-plusplus': 'off',
    'consistent-return': 'off',
    'import/no-extraneous-dependencies': 'off',
    'no-underscore-dangle': 'off',
    'import/no-named-as-default-member': 'off',
    'semi': ['error', 'always'],
    'node/no-callback-literal': 'off'
  }
};

• 忽略文件

在项目根目录新建一个.eslintignore文件，然后写入需要忽略检查的文件

• 规则优先级

行内配置>命令行选项>项目文件配置

stylelint

stylelint是一个检查css样式的规范的工具

• 安装
  这里安装是基于项目来安装的，并不是全局安装的，全局安装就会使项目环境依赖于全局环境了

npm i stylelint -D

• 命令

下面2个命令是比较常用的

检查根目录下的任意目录的html,vue,css,sass,scss文件是否符合代码规范

stylelint **/*.{html,vue,css,sass,scss}

自动修复代码规范

stylelint **/*.{html,vue,css,sass,scss} --fix

• 配置

在项目根目录新建.stylelintrc.js文件。下面的配置是基于css和scss样式文件的，如果需要支持less可自行进行配置

module.exports = {
  // 需要安装 stylelint-config-standard，stylelint-config-recommended-scss（处理scss样式），stylelint-config-recess-order
  extends: [
    'stylelint-config-standard',
    'stylelint-config-recommended-scss',
    'stylelint-config-recess-order',
  ],
  // 需要安装stylelint-scss，scss 拓展，增加支持 scss 语法
  plugins: ['stylelint-scss'],
  rules: {
    'no-descending-specificity': null,
    'no-empty-source': null,
  },
};

• 忽略文件

在项目根目录新建一个.stylelintignore文件，然后写入需要忽略检查的文件

• 规则优先级

行内配置>命令行选项>项目文件配置

prettier

prettier是一个自动格式化代码的工具

• 安装

npm i prettier -D

• 使用

npx prettier --write

格式化指定文件

npx prettier --write src/index.js

• 配置文件

在项目根目录下新建.prettierrc文件，当然也可以是.json，.json文件结尾

module.exports = {
    printWidth: 80, //一行的字符数，如果超过会进行换行，默认为80
    tabWidth: 2, //一个tab代表几个空格数，默认为80
    useTabs: false, //是否使用tab进行缩进，默认为false，表示用空格进行缩减
    singleQuote: false, //字符串是否使用单引号，默认为false，使用双引号
    semi: true, //行位是否使用分号，默认为true
    trailingComma: 'none', //是否使用尾逗号，有三个可选值"
}

统一编辑器风格

不同的编辑器的风格可能会不一样，我们要统一一下风格。在项目跟目录下新建.editorconfig文件

[*.{js,jsx,ts,tsx,vue}]
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true

属性:

indent_style    设置缩进风格(tab是硬缩进，space为软缩进)
indent_size     用一个整数定义的列数来设置缩进的宽度，如果indent_style为tab，则此属性默认为tab_width
tab_width       用一个整数来设置tab缩进的列数。默认是indent_size
end_of_line     设置换行符，值为lf、cr和crlf
charset         设置编码，值为latin1、utf-8、utf-8-bom、utf-16be和utf-16le，不建议使用utf-8-bom
trim_trailing_whitespace  设为true表示会去除换行行首的任意空白字符。
insert_final_newline      设为true表示使文件以一个空白行结尾
root           表示是最顶层的配置文件，发现设为true时，才会停止查找.editorconfig文件

husky/lint-staged

husky是一个git hook工具，可以利用husky在git提交代码之前检查代码是否符合规范，如果不符合就不允许提交代码。

lint-staged是一个可以让husky只检验git工作区的文件，否则可能会导致出现很多问题

• 安装

npm i husky -D

npm i lint-staged -D

• 使用

在package.json文件中，新增配置

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
    "lint-staged": {
    "*.{html,vue,css,sass,scss}": [
      "stylelint **/*.{html,vue,css,sass,scss} --fix"
    ],
    "*.{js,vue}": [
      "prettier --write",
      "eslint --fix --ext .js,.vue ./",
      "git add",
      "eslint --ext .js,.vue ./"
    ]
  },

在git commit之前会进入工作区扫描，这里需要注意的是先执行prettier --write，然后再执行eslint --fix --ext .js,.vue ./，否则后面的eslint --ext .js,.vue ./可能会执行不通过，修复完成后自动提交到工作区

Commitizen

Commitizen是一个格式化commit message的工具

• 安装

npm install commitizen -D

• 配置

在package.json文件，新增如下配置

  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }

上面的配置都是英文的说明，如果你想来点中文提示，可以这样配置

  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    },
    "types": {
      "feat": {
          "description": "新增功能",
          "title": "feat"
        },
        "fix": {
          "description": "bug 修复",
          "title": "fix"
        },
        ...
    }
  }

• 使用

使用git cz命令代替git commit

自定义Commitizen提交说明

如果你不需要自定义提交说明，就跳过这一步，这个需要用到cz-customizable适配器

• 安装

npm i cz-customizable -D

• 修改配置

在package.json中修改commitizen.path配置

"config": {
  "commitizen": {
    "path": "node_modules/cz-customizable"
  }
}

• 新增配置文件

在项目的根目录下新建.cz.config.js文件：

module.exports = {
  types: [
    {value: 'feat',     name: '新增功能'},
    {value: 'fix',      name: 'bug 修复'},
    {value: 'docs',     name: '文档更新'},
    {value: 'build',    name: '主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交'},
    {value: 'refactor', name: '重构代码(既没有新增功能，也没有修复 bug)'},
    // ...
  ],

  scopes: [
    {name: '模块1'},
    {name: '模块2'},
    {name: '模块3'},
    {name: '模块4'}
  ],

  // it needs to match the value for field type. Eg.: 'fix'
  /*
  scopeOverrides: {
    fix: [
      {name: 'merge'},
      {name: 'style'},
      {name: 'e2eTest'},
      {name: 'unitTest'}
    ]
  },
  */
  // override the messages, defaults are as follows
  messages: {
    type: '选择一种你的提交类型:',
    scope: '选择一个scope (可选):',
    // allowCustomScopes=true时使用
    customScope: 'Denote the SCOPE of this change:',
    subject: '短说明:\\n',
    body: '长说明，使用"|"换行(可选)：\\n',
    breaking: '非兼容性说明 (可选):\\n',
    footer: '关联关闭的issue，例如：#31, #34(可选):\\n',
    confirmCommit: '确定提交说明?'
  },

  allowCustomScopes: true,
  allowBreakingChanges: ['特性', '修复'],

  // limit subject length
  subjectLimit: 100

};

Commitizen校验

提交前先检验提交的信息是否规范，不规范则不可以提交

• 安装

npm i @commitlint/cli -D

npm i @commitlint/config-conventional -D

• 配置

在项目根目录下新建.commitlintrc.js文件，写入如下配置

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'build', // 主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
        'ci', // 主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
        'docs', // 文档更新
        'examples', // 开发测试
        'feat', // 新增功能
        'fix', // bug 修复
        'perf', // 性能优化
        'refactor', // 重构代码(既没有新增功能，也没有修复 bug)
        'style', // 不影响程序逻辑的代码修改(修改空白字符，补全缺失的分号等)
        'test', // 新增测试用例或是更新现有测试
        'revert', // 回滚某个更早之前的提交
        'chore' // 不属于以上类型的其他类型(日常事务)
      ]
    ]
  }
};

然后在package.json文件中配置husky，上面已经安装过了，直接添加配置

"husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      // 新增如下配置
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  }

vscode集成

我们可以借助vscode的插件，在保存的时候根据eslint和stylelint的配置进行自动修复。还有其他功能等。

• 在vscode的扩展中搜索ESLint和stylelint，然后安装

• 在项目根目录新建.vscode文件夹，在该文件夹下面新建settings.json文件，并写入如下配置

{
    "eslint.validate": [
      {
        "language": "vue",
        "autoFix": true
      },
      {
        "language": "html",
        "autoFix": true
      },
      {
        "language": "javascript",
        "autoFix": true
      },
      {
        "language": "javascriptreact",
        "autoFix": true
      },
      {
        "language": "tyypescript",
        "autoFix": true
      }
    ],
    "eslint.autoFixOnSave": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true,
        "source.fixAll.stylelint": true
    }
  }

• git提交记录。安装Git History Diff可查看文件的每一行提交记录，这样就可以很方便的查找出是谁提交的记录。

webpack集成

在开发过程中，我们把那些不符合代码规范的错误显示在浏览器和控制台中，这样就可以及时的去修复代码不规范的问题，而不是在最后提交代码的时候运行eslint --fix

• 安装插件

npm i eslint-webpack-plugin stylelint-webpack-plugin -D

• 添加插件

在webpack.config.js文件中添加以下配置

const ESLintPlugin = require('eslint-webpack-plugin');
const StylelintPlugin = require('stylelint-webpack-plugin');

module.exports ={
  plugins: [new ESLintPlugin(), new StylelintPlugin()]
}

gulp集成

如果你使用的是gulp，并且需要把那些不符合代码规范的错误显示在浏览器和控制台中，那么你需要这么做：

• 安装插件

这里需要注意的是，如果你是用的是eslint版本大于7，需要安装gulp-eslint7，否则就安装gulp-eslint

npm i gulp-eslint7 gulp-stylelint -D

• 配置

const { src, dest } = require('gulp');
const eslint = require('gulp-eslint7');
const gulpStylelint = require('gulp-stylelint');

const buildCss = (srcPath, distPath) => () =>
  src(srcPath)
    .pipe(
      gulpStylelint({
        reporters: [{ formatter: 'string', console: true }]
      })
    )
    .pipe(dest(distPath));

const buildJs = (srcPath, distPath) => () =>
  src(srcPath)
    .pipe(eslint())
    .pipe(eslint.format())
    .pipe(eslint.failAfterError())
    .pipe(dest(distPath));

总结

到此，一套前端代码工作流已经搭建完毕了。需要注意的是，上面这套前端代码工作流是我搭建组件库的时候研究总结出来的，特别适合那些自己搭建一个vue环境项目的场景。如果你是使用vuecli脚手架，那么就应该可以省去很多流程了，毕竟脚手架已经集成了这些东西，你只需要选择对应的选项即可。如果你使用的是react或者微信小程序，也可以参照这套工作流，就是在eslint的配置或者stylelint的配置上面有所差别而已。

其他

vue2组件库：https://github.com/c10342/lin-view-ui
微信小程序组件库：https://github.com/c10342/lin-wx-ui

上面2个组件库都是由我个人开发维护的，都是使用了上面那套前端代码工作流流程。有兴趣的同学可以去参考一下，或者下方留言一起学习交流。