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 的未来感到非常兴奋，我们也将解决一些更困难的问题，例如让所有规则都支持自动修复，以及将类型信息纳入我们的分析。当我们共同使用同一个工具时，我们可以更快地取得更大的进展。
- 尼古拉斯
