Lint添加到Taro（VUE风格）项目中？在讨论如何去做之前，我们有必要给Lint一个清晰准确的定义。维基百科的定义如下：在计算机编程中，lint是一种Unix实用程序，用于标记C语言源代码中的一些可疑和不可移植的构造（可能是错误）；通常，lint或linter是标记以任何计算机语言编写的软件中可疑使用情况的任何工具。术语lint-like行为有时适用于标记可疑语言使用的过程。类似Lint的工具通常对源代码进行静态分析。简单的说，Lint是一个对代码进行静态分析，试图发现潜在问题的工具。在实战中，我们也用Lint来指代使用工具的过程。为什么是林特？使用Lint有什么好处？在我看来，它至少有以下三点：bug少，剑桥大学研究发现，全球每年因软bug造成的经济损失约为3120亿；更高的开发效率，工程师平均会花50%的时间在工作时间定位和解决各种bug，其中很多是明显的低级错误，而Lint可以轻松发现低级和明显的错误；更高的可读性，代码可读性的首要因素是“表面文章”，网上看起来乱七八糟的表面代码通常更难阅读；可以直白的说，不做Lint，就是在浪费自己的时间，浪费团队的资源。为Taro脚手架生成的项目添加eslint支持。一般来说，在VUE项目中，@vue/cli生成的项目会自动安装所需的npm依赖，并在package.json中生成相关的eslint命令。但是对于一个基于Taro的VUE风格的项目，我们也希望在开发同学提交代码（gitcommit）之前检查一下代码规范，以免后期不断修改代码有味道等麻烦。但是@tarojs/cli在生成项目时，并不会像@vue/cli创建项目时那样自动安装所需的npmlib，也不会在package.json中生成相应的命令。那么我们如何在taro项目中配置eslint和git工作流检测触发器呢？安装ESLINT相关依赖首先我们配置eslint本身。需要安装的npm依赖如下：npminstall--save-deveslinteslint-plugin-vue//用于安装eslint和适用于vue文件模板部分的lint规则npmi@vue/eslint-config-standard--save-dev//为了使用更严格的vue模板代码规则，需要安装这条规则npminstalleslint@7.11//由于eslint-config-standard依赖eslint>7.11，所以需要确认本地的eslint版本是否满足上述规则的安装要求，一般来说，我们对taro生成的vue项目进行代码检查就足够了。接下来，如果我们需要对eslint规则的应用进行特殊配置，请修改项目根目录下的.eslintrc.js文件。由于我们需要对vue文件进行代码规则检测，所以需要在.eslintrc.js文件中添加一个extends属性：module.exports={...,extends:['plugin:vue/recommended','@vue/standard'],...}更多细节请参考https://eslint.org/docs/user-...githooks配置这里首先介绍友达在中使用的yorkie库看。当yorkie包执行vuecreate命令时，会安装一个包叫：yorkie。这个包是来自husky的叉子。它们都具有相同的功能。他们都生成一些githooks文件并读取项目中的package.json。执行一些命令的相关配置项，不同的是友达做了一些逻辑和配置的改动。安装这个包后，会自动执行yorkie包中的一个脚本：bin/install.jsyorkie包安装完成后，会在你项目下的.git/hooks目录下生成很多githooks文件：?projectgit:(dev)?ls.git/hooksapplypatch-msgcommit-msg.samplepost-checkoutpost-receivepost-update.samplepre-auto-gcpre-pushpre-rebase.sampleprepare-commit-msgsendemail-validateapplypatch-msg.samplefsmonitor-watchman.samplepost-commitpost-rewritepre-applypatch预提交pre-push.samplepre-receiveprepare-commit-msg.sampleupdatecommit-msgpost-applypatchpost-mergepost-updatepre-applypatch.samplepre-commit.samplepre-rebasepre-receive.samplepush-to-checkoutupdate.sample这时候，当你执行一些git命令的时候，比如：gitpush，gitcommit等，git会执行相应的钩子。package.json之后，在执行gitcommit命令时，git会执行pre-commithook。hook执行的内容，可以看到在package.json中一般已经配置好了，我们来看看在rivendell项目中是如何配置的："gitHooks":{"pre-commit":"lint-staged"}lint-staged现在如果我们执行gitcommit命令，githooks会自动执行相应的命令，但是这时候你可能会得到一个错误信息（如果是vue项目，已经作为依赖安装），告诉你你需要安装lint-staged，让我们看看lint-staged是做什么用的。如果在每次代码提交前执行eslint检测所有文件中的代码规则问题，如果代码触发了规则不允许的代码风格，所有问题都会输出：warning:Prop'isAddOrEdit'requiresdefaultvaluetobeset(vue/require-default-prop)在src/view/split/setting/templateEditDialog.vue:112:5:110|导出默认值{111|道具：{>112|isAddOrEdit:{|^113|类型：字符串114|}115|},error:'webpack'在vue.config.js:2:7:1|处被分配了一个值但从未使用过(no-unused-vars)constpath=require('路径')>2|constwebpack=require('webpack')|^3|constfs=require('fs')4|常量SentryWebpackPlugin=require('@sentry/webpack-plugin')5|constos=require('os')错误：在vue.config.js:4:7:2|'SentryWebpackPlugin'被分配了一个值但从未使用过（no-unused-vars）constwebpack=require('webpack')3|constfs=require('fs')>4|常量SentryWebpackPlugin=require('@sentry/webpack-plugin')|^5|constos=require('os')6|constresolve=dir=>{7|returnpath.join(__dirname,dir)错误：在vue.config.js:5:7:3|为'os'分配了一个值但从未使用过(no-unused-vars)constfs=require('fs')4|常量SentryWebpackPlugin=require('@sentry/webpack-plugin')>5|constos=require('os')|^6|constresolve=dir=>{7|返回路径。加入（__dirname，dir）8|}找到27个错误和223个警告。30个警告可能可以使用`--fix`选项修复。错误！代码ELIFECYCLEnpm错误！错误号1npm错误！member-admin-site@1.0.0lint：`vue-cli-servicelint`npm错误！退出状态1npmERR!npmERR!在member-admin-site@1.0.0lintscript.npmERR失败！这可能不是npm的问题。上面可能有额外的日志记录输出。可以看到，如果项目没有进行过代码风格测试，一下子检测出超过10000个lint错误。即使是代码规范改正的项目，有时其他同学的代码也会出现lint问题。提交代码的时候，反馈提交不了代码，很烦人。所以有了lint-staged的能力，当大家有新的提交时，只对修改后的代码进行代码检测，解决了这个问题。Feedly工程师AndreyOkonetchnikov开发的lint-staged就是基于这个想法。Staged是Git中的一个概念，指的是提交区。当你使用gitcommit-a，或者先gitadd然后再gitcommit时，你修改的代码会通过pendingsubmission区域。lint-staged的使用方法如下：首先安装依赖：npminstall-Dlint-staged然后修改package.json配置，添加如下入口："lint-staged":{"*.{js,jsx,vue}":["eslint--fix",//--fix模式是可选的，如果你想在lint检测后自动修复，添加这个模式参数，如果你仍然希望开发者手动修复它，你可以这样做没有这个参数"gitadd"]}小结从0到1的项目开发初期，我们可能没有精力去关注代码风格和良好的格式。但是不好的代码风格可能会隐藏很多不容易发现的bug，给后面接手修改的同学带来很大的麻烦。一个不规则的代码文件让读者一头雾水，让小编一直到凌晨都无法理清其中千丝万缕的逻辑关系。而接手的人可能在几个月后就是你自己。因此，代码规范和格式的改进不是浪费时间，而是以后更好的保命方法。拯救你的生命也拯救别人的生命
