ESLint 和 JSCS 大约在同一时间起步，2013 年仅相隔三周。 两个团队都有一个相似的想法：利用与 ESTree 兼容的工具（如 Esprima）的生态系统，创建下一代 JavaScript 静态分析工具。 虽然 ESLint 的主要目标是创建一个具有可插拔规则的 linter，但 JSCS 的主要目标是编纂风格指南，以便于验证和修复。 两个项目都发展壮大并变得流行，很快，我们发现自己在功能方面彼此追赶。
近三年来，两个团队一直在努力解决相同类型的问题：如何共享配置、如何自动修复一些问题，以及如何使各自的生态系统发展壮大。 我们一直在并行做很多相同的工作，最近两个团队会面讨论了这个问题。 我们都得出结论，最好成为一个团队，共同解决这些问题，而不是继续相互竞争。
在下面，您将找到更多关于我们如何作为一个团队前进以及我们对 JSCS 和 ESLint 的计划的详细信息。
欢迎 JSCS 团队
我很高兴地宣布，JSCS 团队即日起成为 ESLint 团队的一部分。 我谨代表大家欢迎 Marat Dulin、Oleg Gaidarenko、Mike Sherov、Alexej Yaroshevich 和 Henry Zhu 的加入，并期待与他们合作。 为了感谢 JSCS 团队成员在 JSCS 上所做的工作，他们都将作为提交者加入 ESLint（基于我们的治理政策）。
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
