飞道的博客

前端代码工作流

425人阅读  评论(0)

编辑器选择

在刚接触前端的时候,我使用的编辑器是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目录下任意目录下后缀名为jsvue的文件是否符合规范

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

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

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文件。下面的配置是基于cssscss样式文件的,如果需要支持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的扩展中搜索ESLintstylelint,然后安装

  • 在项目根目录新建.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个组件库都是由我个人开发维护的,都是使用了上面那套前端代码工作流流程。有兴趣的同学可以去参考一下,或者下方留言一起学习交流。


转载:https://blog.csdn.net/vgub158/article/details/116607654
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场