ESLint 和 JSCS 几乎同时起步，仅相差三周，时间是在 2013 年。这两个团队都有着类似的想法：利用 Esprima 等兼容 ESTree 的工具生态系统来创建下一代 JavaScript 静态分析工具。虽然 ESLint 的主要目标是创建一个具有可插拔规则的代码检查工具，但 JSCS 的主要目标是将代码风格指南规范化，以便于验证和修复。这两个项目都发展壮大并广受欢迎，很快，我们发现自己在功能上相互追赶。
近三年来，这两个团队一直在解决相同类型的问题：如何共享配置、如何自动修复一些问题以及如何使各自的生态系统发展壮大和繁荣。我们一直在平行地做很多相同的工作，最近这两个团队会面讨论了这个问题。我们都得出结论，与其继续相互竞争，不如组成一个团队，共同解决这些问题。
下面，您将找到更多关于我们如何作为一个团队前进以及我们对 JSCS 和 ESLint 的计划的详细信息。
欢迎 JSCS 团队
我很高兴地宣布，JSCS 团队现已正式加入 ESLint 团队。我邀请大家欢迎 Marat Dulin、Oleg Gaidarenko、Mike Sherov、Alexej Yaroshevich 和 Henry Zhu 加入，我们期待与他们合作。所有 JSCS 团队成员都将以贡献者身份加入 ESLint（基于我们的 治理政策），以表彰他们在 JSCS 上的工作。
Joel Kemp 已决定专注于其他工作，不会加入 ESLint。我以及团队的其他成员也感谢 Joel 多年来对 JSCS 的诸多贡献。
JSCS 3.0.0
今天，JSCS 发布了 3.0.0 版本，这将是 JSCS 的最后一个主要版本。此版本已重写为使用具体语法树 (CST) 而不是抽象语法树 (AST)。CST 的概念在 JavaScript 生态系统中已经存在了一段时间，而 JSCS 3.0.0 代表了第一个在生产环境中完全实现 JavaScript CST 使用的工具。因此，我们确实需要来自 JSCS 社区的反馈，因为我们很有可能在未来的 ESLint 中使用相同或类似的方法。
如果您是当前的 JSCS 用户，我强烈建议您升级到 3.0.0 并报告您的使用体验。JSCS 团队将在短期内继续维护 JSCS，修复报告的错误。
使 ESLint 适用于 JSCS 用户
我们认识到 JSCS 拥有一个庞大而活跃的用户群，因此，合并后的 ESLint/JSCS 团队的首要目标是使 JSCS 用户轻松过渡到 ESLint。为此，我们的短期计划包括以下任务
- 识别 JSCS 中存在但在 ESLint 中缺失的规则，并创建尽可能多的这些规则。(#5856)
- 整合一种将
.jscsrc文件转换为.eslintrc文件的方法，目标是实现一个自动执行此操作的单一命令。(#5857) - 为最流行的 JSCS 预设创建 ESLint 可共享配置。(#5858)
- 扩展 ESLint 的自动修复功能，以修复更多问题，并尽可能接近 JSCS 2.x 中提供的自动修复级别。
- 编写文档以指导 JSCS 用户过渡到 ESLint。(#5859)
查看我们关于上述任务的里程碑 此处。
我们预计这项工作将需要几个月的时间，因此，我们仍然鼓励当前的 JSCS 用户升级到 JSCS 3.0.0 并向团队提供反馈。我们将在完成支持 ESLint 中 JSCS 用户所需的所有更改后宣布，届时将开始鼓励 JSCS 用户切换到 ESLint。
未来一片光明
随着新的合并后的 ESLint/JSCS 团队的成立，您可以期待 ESLint 在未来有更多发展。我们现在拥有一些世界上最优秀的人才，致力于使 ESLint 成为 JavaScript 语法分析的最佳工具。我个人对 ESLint 的未来以及解决一些更困难的问题（例如，使每个规则的自动修复成为可能，并将类型信息整合到我们的分析中）感到非常兴奋。当我们都在使用同一个工具时，我们可以走得更远，更快。
- Nicholas
