前端工程化(3)—带你系统的过一遍项目的规范化

土豆丝爱学习
473 阅读9分钟

文章内容输出来源：拉勾教育大前端高薪训练营；

前言

前端工程化中很重要的一个环节是制定规范化的标准，能保证多人协作时，代码风格更规范，减少问题代码，使项目更好维护。

如果日常开发没用过lint的，可以通过本篇文章，建立一个笼统的印象，等需要的时候再回来针对性使用。如果使用过的，可以看着文章，建立一个系统的概念，查缺补漏。

规范化介绍

什么是项目中的规范

代码、文档、甚至是提交日志，只要是开发过程中人为编写的，都可以制定统一的规范。其中代码规范最重要：统一关键词和操作符之间的空格，统一代码缩进方式，统一变量或者函数的命名规范，统一是否使用分号结尾...

怎么在项目中实施规范

最简单的方式就是项目开发前，团队中约定好规范，统一按照约定进行开发。但弊端很多：每来新人，都需要学习团队规范，学习成本增加;开发者开发过程中，要时刻记得规范，容易分心；3.管理者要保证每个开发者都遵循规定，不会擅自提交不符合规定的代码...

所以，需要引进工具，来强制执行规范——lint工具。

ps: lint说法来源于c语言，创建用来检测代码的工具，后来其他语言也沿用了这一说法，所有用于检验代码的工具，统称为lint。前端常用的是eslint，stylelint等

eslint——常见规范化实现方式

eslint的介绍

  • 最为主流的js lint工具，监测js代码质量
  • eslint很容易统一开发者的编码风格
  • eslint可以帮助开发者提升编码能力

eslint工具的使用

安装

npm init -y
npm i eslint --D
npx eslint --version

初始化配置文件：根据命令行的问题，选择对应的答案。

npx eslint --init

注：syntax校验语法；find problem发现问题代码；enforce code style统一代码风格 模块化规范选择: 是否允许出现指定的语法或者调用 选择使用的框架：会根据选择自动下载关于vue 或者 react项目用到的插件 代码风格如何定义？ 1：使用流行风格；2.回答问题生成风格 3.根据js文件推断你的风格 常见的三种风格，一般我用standard，关于这些规则具体介绍，可查看对应的网址介绍 配置文件的格式，一般选择js，可使用判断语句 下载依赖完成后，可自动生成配置文件——eslintrc.js,该配置文件会影响当前目录以及子目录的代码，正常情况下，不会手动修改，一般只用来关闭/开启某个校验规则。 准备一个有问题的js代码，来测试eslint的使用

准备要测试的文件

（后面测试文件可自己准备，随便写点代码即可）

//test.js  要eslint的文件
const foo=123  问题代码：声明未使用

function fn() {
    console.log('hello')

        console.log('eslint')


}   // 风格问题：空格乱

fn(  //语法问题
syy()  //问题代码：未声明使用

执行检测命令

npx eslint .\test.js（文件名）

会先检测语法问题，语法问题解决完后，再次 npx eslint .\test.js才会报不规范代码和风格的检测解决完， npx eslint .\test.js --fix 1、先把语法问题解决完 --fix才有效 2.风格类的代码可以自动修复。其他需要根据提示手动修改

eslint校验规则——配置

  • 全局配置 eslintrc.js
module.exports = {
  env: { //标记当前代码的运行环境。eslint会根据环境信息来判断有哪些全局成员是可用的，从而避免代码中使用不存在的成员。eg： browser: false,在代码中使用alert会报错。具体可使用的环境变量有24个，不互斥，可叠加。
    browser: true,
    es2021: true
  },
  extends: [ //继承一些共享的配置
    'standard'
  ],
  parserOptions: { //设置语法解析器的配置
    ecmaVersion: 12 //控制使用某个es版本的语法 eg：值为5，则代码中不可以出现es6语法
  },
  rules: {
  //用来配置某个校验规则的开启或者关闭
  },
  globals: {
  //额外声明代码中可用的全局变量。eg：代码中使用$,要声明$:"readonly"
  }
}
  • 注释配置

将配置直接通过注释的方式写到脚本文件中，再执行校验。
存在原因：项目中难免会有1-2个需要违反项目规则的地方

//eslint-disable-line  [要禁用的规则]
eg：//eslint-disable-line  no-template-curly-in-string

规则来自于eslint命令行的提示，不仅可以禁用某个规则，还可以声明全局变量，修改某个规则的配置。临时开启某个环境 等等。更多可查看 eslint.cn/docs/

typescript\vue\react + eslint

现代化项目对eslint集成都很友好且方便，创建项目时选择eslint，或者eslint初始化时选择对应模块，都可自动生成对应的配置文件，基本不需要修改，非常方便

vue

方式一：vue create my-app时，在命令行选择lint on save 和 lint and fix on commit 即可在新建的项目在自动初始化eslint，并设置好 git hook

方式二：vue老项目里，npm i eslint，npx eslint --init 时，选择vue框架，即可自动生成针对vue项目的配置文件

module.exports = {
  root: true,
  env: {
    node: true
  },
  extends: [
    'plugin:vue/essential',
    '@vue/standard'
  ],
  parserOptions: {
    parser: 'babel-eslint'
  },
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off'
  }
}

react

同上，在react项目中，npx eslint --init 时选择 react即可

关于用eslint检测ts

同上，npx eslint --init 时选择 ts即可。（项目中ts一定要先下载好，在npx eslint --init ）

module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "standard"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 12
    },
    "plugins": [
        "@typescript-eslint"
    ],
    "rules": {
    }
};

git hooks 原理

通过vue-cli创建项目时，可自动选择配置好eslint-staged，其他通过npx eslint --init 方式添加的eslint，都需要手动添加 git hook。

  • 介绍
    git hook 即git 钩子，每个钩子都对应一个任务，eg：push。commit...，通过shell脚本可以编写钩子任务触发时要具体执行的操作。比如这里要用到的，在precommit时，强制执行 lint。

  • husky
    许多前端开发者并不擅长使用 shell，husky（一个npm 依赖包）可以实现git hooks的使用需求。 npm i husky -D

//package.json
"scripts":{
	"test": "eslint ./index.js"
}
"husky":{
	"hooks":{
    	"pre-commit":"npm run test"
    }
}
  • lint-stages
    不仅验证precommit，验证之后，还可以做其他操作 npm i lint-stages -D
{
 ...
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js}": [
      "eslint",
      "git add"
    ]
  }
}

gulp或者webpack集成eslint

有时候我们需要在自己构建的自动化项目中，引入eslint，只有就可以在代码babel之前，先eslint一遍。

gulp

  • 准备：找到上一节我们使用gulp创建的自动化构建项目。先下载对应依赖
npm i gulp-eslint  eslint
npx eslint --init
  • script：找到编译js代码的任务
const script = () => {
  return src('src/assets/scripts/*.js', { base: 'src' })
  	//js代码babel之前先eslint
    .pipe(plugins.eslint()) //检测代码中问题
    .pipe(plugins.eslint.format()) //在控制台打印出错误信息
    .pipe(plugins.eslint.failAfterError()) //遇到错误中止管道继续执行
    
    .pipe(plugins.babel({ presets: ['@babel/preset-env'] }))
    .pipe(dest('temp'))
    .pipe(bs.reload({ stream: true }))
}
  • 使用： 导出临时任务测试：npx gulp script
module.exports = {
    script
}

webpack

通过 loader 机制实现集成

  • 准备：关于webpack的还未整理，先给大家提供一个关于webpack的项目，供测试github.com/zce/zce-rea…
npm i eslint-loader  eslint  -D
npx eslint --init //初始化init：不选module和react

(如果 npx eslint --init时报错，未找到 package.json，不用管，再执行一次npx eslint --init即可)

module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "standard"
    ],
    "parserOptions": {
        "ecmaVersion": 12
    },
    "rules": {
    }
};
  • 使用：添加一个新的配置规则，代码逻辑更清晰
 {
      test: /\.js$/,
      exclude: /node_modules/,
      use: 'eslint-loader',
      enforce: 'pre'
  },
  • npx webpack。出现下面效果，说明引入eslint 成功

其它工具

lint工具本身并不难，重要的是举一反三，灵活使用。学了对js文件的检测，顺便探索对其他文件的格式化。了解即可，日常开发中我没有用过

stylelint

css代码的lint，使用上与eslint 一致

1.npm init -y
npm i stylelint -D
npm i stylelint-config-standard stylelint-config-sass-guidelines -D 没有默认的校验模块。需要下载插件

2.新建.stylelintrc.js 文件

module.exports = {
    extends:[ 
    	"stylelint-config-standard",  //处理.css文件
    	"stylelint-config-sass-guidelines"   //处理.sass文件
        ...
    ]
}

3.npx stylelint 文件
npx stylelint 文件 --fix

prettier

前端代码自动格式化工具，支持多种文件，css\scss\js\html\md...

npm i prettier -D
npx prettier 文件名  //默认将格式化后的代码输出到命令行
npx prettier 文件名 --write  //--write 用格式后代码重写原文件

总结

今天主要分享了前端工程化中引入规范化标准的实现，首先，我们需要掌握 eslintrc.js 的配置文件的属性，知道如何制定关于自己项目的校验规则。从网上下载别人的代码，如果带eslint，也知道报错的原因，以及如何调整。其次，需要掌握如何在自己的项目中引入eslint，帮助多人协作时，进行代码校验。

最后，给大家分享一下我使用eslint的感觉，刚开始写的项目小，自己一个人负责，不需要使用eslint，毕竟一看见各种报错就很烦，很耽误时间。后来维护别人的老项目，也不会使用eslint，毕竟一上eslint就会各种报错，维护都花功夫，不可能再改代码的规范。不过看别人的代码很麻烦，如果当初别人使用了eslint，我们维护的时候，会方便很多。再再后来，负责的项目更大了，不仅要自己敲代码，还带几个人的小团队，大家代码最终汇总到一起，经常一运行，就报各种错，帮他们看代码，一看就头疼...于是毅然决然在项目中引入了eslint, 我的感悟就是项目如果维护周期长，项目大，协作人员多，满足任一条件，一定要使用eslint。自己一个人的时候，也要先体验试试，避免以后团队协作，自己写的代码不规范，老是校验不通过，改代码耽误时间。

如果你使用的是vscode，关于eslint有一些自动格式化工具，可以下载配合使用。不过我建议，前期还是先自己手动修改，后期再慢慢引入格式化工具。

今天关于eslint的先分享到这里，新手尝试码文，有不对的地方欢迎大家指导。同时，关于eslint的一些问题，也欢迎大家在评论区讨论。下次趁国庆长假，整理一下wabpack，感兴趣的可以关注一下。

本系列其他

avatar
文章
阅读
粉丝