给老项目加入eslint的建议

本文属于原创文章,转载请注明–来自桃源小盼的博客

前言

通常关于eslint的文章是介绍如何使用。这里会假定一个前提,这是一个新项目。今天我们聊聊老项的一些使用建议。

尽快确定一种风格

很多团队会陷入一种争论,到底选择哪种风格,通常有airbnbstandard等。也有一些团队会认为这几种风格都不是我想要的,要自己定制。

此时,我们忽略一个问题,我们做这件事最重要的目的是什么?

有两个目的,一是自动检查错误;二是统一团队代码风格,增强维护性。

不论哪种风格,都会检查错误,那么统一风格才是主要的目标,而不是选择哪种风格。

所以不论是民主投票,还是leader做决定,或者其他办法。都请尽快确定风格,并且有了prettier后,写代码的过程中工具会帮你自动改正的。

不用追求完美

当我们在一个老项目中加入eslint后,会发现报错信息多到爆炸,我相信程序员中有很多强迫症,想立刻修复这些错误。

但我请你先停下来,思考一个问题,你能确保自己的修改,不会导致任何问题吗?
答案是不能。

同时还有几个事情需要考虑:

  • 有一些错误或警告,需要读懂原来的代码,并进行修复
  • 古老的项目,有太多的文件需要修复
  • 有一些修复需要完整的测试

上面这三件事情会耗费团队很多精力,并且有些团队有很多古老的项目。工作量太庞大了,如果我们把大量的精力浪费在这里,不是最好的选择。

过去的代码,虽然它丑陋,但大都经过了充分地测试,是可以正常运行的代码。我们的主要目标是约束未来的代码。

我的办法

因为我个人有代码洁癖,所以做了一些更精细的操作。

  1. 有一些规则,像缩进都改成两个空格,这类的规则全都使用工具来解决掉。
  2. 给所有文件增加eslint-disable 注释,并规范团队,在未来如果修改这个文件,需要删除注释并修复。

因为我们团队采用了vue,所以写了一个批量添加注释的脚本工具。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#! /bin/sh
if [ $# -lt 1 ]
then echo '请填写路径'
exit
fi
{
num=0
function e(){
for file in `ls $1`
do
if [ -d $1"/"$file ]
then
e $1"/"$file $2
else
if [ "${file##*.}"x = "js"x ]||[ "${file##*.}"x = "ts"x ]
then
echo $1"/"$file"\n"
num=`expr $num + 1`
# sed -i '' 1d $1"/"$file
sed -i '' '1 i\
/* eslint-disable */
' $1"/"$file
else
if [ "${file##*.}"x = "vue"x ]
then
num=`expr $num + 1`
# sed -i '' 1d $1"/"$file
sed -i '' '1s/\<template\>/\<template\>\'$'\n\<!-- eslint-disable --\>/' $1"/"$file
sed -i '' '1s/\<template lang="html"\>/\<template lang="html"\>\'$'\n\<!-- eslint-disable --\>/' $1"/"$file
sed -i '' 's/\<script\>/\<script\>\'$'\n\/* eslint-disable *\//' $1"/"$file
sed -i '' 's/\<script lang="ts"\>/\<script lang="ts"\>\'$'\n\/* eslint-disable *\//' $1"/"$file
fi
fi
fi
done
}
}
e $1 $2
echo "共修改"$num"个js、ts、vue文件"

结语

推荐望闻问切这种古老的中医方法,多看项目代码,找熟悉的人咨询,将具体的策略和团队一起探讨。

希望大家根据自己的项目情况,做出更好的决策。