JS作为一门动态类型的语言，在给开发者带来便利的同时，也不可避免的引起一些潜在问题。简单来说，它需要你在编程的时候充分的了解当前对象是否有你要使用的方法或者属性。

然后人脑毕竟是有限的。所以就需要一些手段帮你找到潜在的问题。这种手段分为两种：

• 类型检查，也即是TypeScript做的事
• 问题（problem）检查，eslint做的事

举个例子，下面的代码展示了二者对各自认为有问题的地方做出提示。

// TS 报错 This expression is not callable.
// 但eslint则认为OK
const anVar = "my var";
anVar();

// 下面的情况可能在算法中比较常见。
// 对于eslint而言，这种代码可能引起潜在的问题。
// 但对TS来说，是被允许的。
while (foo -= 2) { // no-cond-assign
  console.log(foo)
}

但其实二者没有特别明确的边界。事实上，二者对多数潜在的错误都会做出提示，比如：

javascript">// TS: Duplicate function implementation
// ESLINT: Identifier 'bar' has already been declared
function bar() {
//
}
function bar() {
//
}

只不过eslint的规则是可扩展的，且非常丰富的，对于使用了TS的项目，如果有需要也可以使用eslint。

有点跑题了，在我们初始化eslint的时候，会有几个选项供我们选择。

$ npx eslint --init

这个意思是说，你想使用eslint做哪些事：

• syntax 语法检查，这个eslint即使什么也不配置，也默认支持的。毕竟如果你的代码本身有语法问题，是根本跑不通的。但我们一般感受不到，因为IDE已经帮你做了这件事了。除非你使用记事本之类的去开发。最后你可能会执行npx eslint somefile.js。所以如果我们使用eslint，就不可能只选择第一个的功能。
• syntax and find problems 该选项会帮你添加推荐的规则，如上文所示的no-cond-assign即不允许在条件判断中赋值。这些可以认为是潜在的问题
• syntax，find problems, and enforce code style。这个选项是除了上边第二条的以外，还包括代码风格的检查。

选择代码风格

实际上，代码风格与潜在的问题边界也不是那么清晰，尤其是一组规则内的配置，比如airbnb的规则，可能即包含潜在的问题，也可能包括代码风格，比如：

javascript">function myfunc(params) {
  params = 'not ok in eslint'
}
// 上边的代码如果使用了airbnb有两个错误
// 1. ssignment to function parameter 'params' 不允许重新给参数赋值
// 2. Missing semicolon 缺少分号

如上，两个错误中，显然第一个是潜在的问题。第二个才是代码风格。

简单总结下：

• TS与eslint的功能并非重合的，eslint的可扩展可能定制更多的团队规范
• 为了保证团队代码风格的统一，有必要是用eslint。
• TS，eslint质量检查，eslint风格检查，（其实prettier更擅长风格检查）他们并非有严格的边界。我们可以同时使用。