手摸手带你实践标准的前端开发规范

概述

掘金上发了"制定本身团队的前端开发规范"帖子以后,有好多人给我说光写规范可不行,要进行实践,这篇文章就是告诉你们怎么将咱们以前写的规范进行实践,光说不练假把式,咱们要在项目中强制执行这些规范。前端

主要使用 husky+lint-staged+eslint 对咱们的规范进行实践,首先给你们介绍一下这几个工具都是干什么用的。vue

  • eslint:就很少作介绍了,你们应该都知道,咱们制定的规范须要用一些配置来实现,这个时候用 eslint 是最好不过的了。git

  • husky:能够用于实各类 Git Hook。这里主要用到 pre-commit 这个 hook,在执行 commit 以前,运行一些自定义操做。github

  • lint-staged:用于对 Git 暂存区中的文件执行代码检测。npm

知道了这几个包的做用以后,咱们开始来给一个项目实现一套在提交代码以前的 eslint 检测。json

ESlint

首先开始配置一下本身的 eslint,你们不要着急,接下来我会放一份纯正的 vue 配置,复制粘贴过来就行,若是是纯 JS、TS、React 的项目,能够根据腾讯的 eslint-config-alloy 配置。bash

开始实践吧:babel

  • 进入你的项目中,我这里新建一个项目开始配置
# 要遵循文件夹命名规范
mkdir eslint_test
cd eslint_test
# 一路回车就行
npm init
# 安装 eslint 和 babel-eslint
npm i eslint babel-eslint -D
# 配置其余的 eslint-config,须要根听说明安装其余依赖
复制代码
  • 接着咱们在项目的根目录下建立 eslint 的相关文件:
# eslint 要忽略的文件
touch .eslintignore
# eslint 的规则
touch .eslintrc.js
复制代码
  • .eslintignore 文件中填写 eslint 要过滤的文件
build/*.js
src/assets
public
dist
复制代码
  • 配置 .eslintrc.js

直接看一下我以前写的制定本身团队的前端开发规范之 eslint,,去 copy 一下我根据制定的 eslint 配置,粘贴到 .eslintrc.js 中便可。编辑器

  • 接下来咱们要配置一下 package.json 里面的执行脚本:
"scripts": {
  "lint": "eslint --ext .js --fix"
}
复制代码

主要是检测 js 代码,而后经过 --fix 把 eslint 能解决的问题都在检测的时候解决掉,好比格式,好比变量合并。函数

OK 了,eslint 的规范咱们已经制定完了,接下来就要在 git 提交代码的时候对咱们所写的代码进行检测了。

husky+lint-staged

先安装一下咱们须要的 npm 包:

npm i lint-staged husky -D
复制代码

接下来要在 package.json 里面配置一下咱们的 git 钩子:

{
  "name": "eslint_test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "lint": "eslint --ext .js --fix"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "src/**/*.{js,vue}": ["npm run lint", "git add"]
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "babel-eslint": "^10.0.2",
    "eslint": "^6.1.0",
    "husky": "^3.0.1",
    "lint-staged": "^9.2.1"
  }
}
复制代码

husky 里面定义了 git 的钩子函数,咱们主要在 commit 以前进行检查,因此用到了 pre-commit 这个钩子。

lint-staged 在 pre-commit 的时候执行,定义了对 git 暂存区中的文件执行的任务,咱们这里只对 js 文件作 eslint 的格式化校验。

可是这里有个小坑,你们必定要注意一下:

由于 pre-commit 这个钩子是须要配合 git 去用的,它主要对文件夹 .git/hooks/pre-commit 文件作手脚,当咱们从 git 上拉下来项目时,若是以前没对 hooks 下的文件作修改,那 hooks 下的文件都是以 sample 结尾的,这个时候钩子函数是不起做用的,当咱们安装了 husky 以后,husky 会自动对 hooks 下面的文件作修改,当你安装完 husky 以后,再打开 .git/hooks 文件夹,你会发现全部的钩子文件,都会存在一份带有.sample 的,一份不带.sample 的,不带.sample 的文件就是 husky 建立的,这个才会让 git 钩子起做用。因此咱们最好是先拉项目,而后再安装 husky,不然可能会致使 husky 失效。若是你是新开发项目,开发完后才提交到 git,开发完以后,你能够先关联 git 仓库,而后从新安装一下 husky 这个包就能够了。

这一套配置下来就能够把咱们以前制定的前端规范强制执行了,怎么样,你会将这一套用到本身的项目中吗?目前我本身就在用,感受仍是很不错的,能够规避不少细节上的问题,若是你还没用上这一套,那你就须要赶快去实践一下了。

开发中代码格式化

上面的主要是在提交代码的时候进行格式化,这样会保证咱们远程 git 仓库里面的代码都是统一的,其实本地开发的时候咱们可使用 prettier 进行格式化,也很是好用,支持不少编辑器,能够自行搜索配置。

阅读完后两部曲

很是感谢各位花时间阅读完,衷心但愿各位小伙伴能够花少许的时间帮忙作两件事:

  • 动动你的手指,帮忙点个赞吧,你的点赞是对我最大的动力。

  • 但愿各位关注一下个人公众号,新的文章第一时间发到公众号,公众号主要发一些我的随笔、读书笔记、还有一些技术热点和实时热点,而且还有很是吸引人的我我的自费抽奖活动哦~

相关文章
相关标签/搜索