hið
我的名字叫Volodymyr，我是SocialTech的Livebeam的软件开发人员，我在这里分享我们的一些经验。
今天，我提供了一个高级概述，概述了我们如何将ESLINT放置到位，并将其缩放在我们的多项式前端项目中。如果您计划提高项目中的代码一致性 - 本文可能只是开始的地方。
前端开发人员熟悉 eslint ，这是一种有助于维持代码质量和捕获错误的好工具。在小型项目中使用时，这是一个相当简单的实用程序。入门所需的只是添加依赖项并通过基本的设置阶段。
但是，如果一个项目已经到位，并且该项目迫切需要覆盖呢？如果该项目由几个团队维护的几个存储库甚至几十个存储库组成，该怎么办？在多个存储库中缩放ESLINT不仅为每个重复重复相同的步骤，还提供了更多。
首先，我将带您进行历史参观，以了解我们如何在多个存储库中标准化的绒毛实践。然后，我将分享我们关于如何与所有警告和错误共存的经验。严格的ESLINT规则将其中的许多人带入了一个成熟项目的生活中。
一切如何开始
让我们看看我们的起点。我们是一个8岁的项目，一直热衷于添加新功能（我们为我们的代码库（缺少代码样式）的一切借口，一个）。我们与多个前端存储库合作 - 有一个通用产品UI，聊天微服务，某些内部用途产品，例如内容审核平台，付款存储库等。尽管我们有代码风格的协议，并且我们的存储库都使用了ESLINT，但我们对事情的运作方式并不完全满意。原因是不同的开发人员正在处理单独的存储库，因此以某种方式，他们都以不同的配置为例。
最初，项目的每个部分都以严格的ESLINT配置开始。随着时间的流逝，决定将一些错误转换为警告。后来，有人自由地完全禁用了这些警告，因为他们好吧，当您发现超出您当前的工作范围的错误时，这会非常烦人，尽管您希望摆脱这些错误，但您却不能。 /p>
缺乏统一设置有什么问题？
不要误会我的意思；开发团队可以将绒毛规则配置为他们的喜好。然而，当团队的任务相交并且您必须窥视彼此的仓库时，这是一个很大的问题，感觉就像前往另一个星球。
我们希望在所有前端代码中都需要相同的绒布规则的原因是统一性。为了实现这一目标，我们需要一个真实的来源，在我们的情况下，我们开发了我们所有项目共享的Eslint库。
我们选择了这种方法，因为规则要长时间保持不变。对外部存储的全局配置进行更改是很多工作，我们希望这种增加的复杂性会阻止我们更改配置规则。通过这种方式，我们促使彼此作为开发人员更改我们的代码，该代码不符合标准，而不是改革标准本身。
我们旨在见证的好处是易于理解。良好的代码读起来像是写得很好的散文（正如罗伯特·马丁（Robert Martin）所说的那样），尤其是当您阅读的代码在格式化方面达到您的期望时，尤其如此。间距，分号和代码块都会影响代码读取的方式。统一编写的代码更容易。您不会觉得代码对您来说是陌生的 - 无论作者如何，它总是感觉更像家。
现在，我记得那时我们在想什么：我们是否会对如何格式化代码有一些激烈的论点。我们做到了。一个是凹痕：2个空间或4个空间？
这是一个有趣的事实，您拥有的标签越长，您的水平空间越快（提供最大规则）。
如果您有4个空间，则缩进4个级别意味着16个空间在最低级别上用完，是2个空间的两倍。当您在课堂或功能中太深时，线长度限制将给出一个提示。发生这种情况时，可能是时候退后一步并重新考虑您当前的做法 - 提取新功能，分解，使用更少的参数，删除嵌套if语句或任何需要的东西，最终将导致更清洁的代码。
是的，是的，花了很多时间才能删除本地存储的配置并切换到库中的配置。我们的规则旋钮几乎变成了0。我们有4个团队从事该项目做很多业务任务。其中一些任务进行了小小的和本地的变化，而另一些则塑造了产品。问题是，不可能仅一一开始对规则进行纠正。也有一个CI/CD平台的棉绒检查，因此代码中标记为“错误”的所有内容都不适合交付。
当我们开始这次旅程时，我们需要要求。
我们决定
- 同意“良好”规则，我们所有人都乐于遵循。
- 不要阻止开发 - 这意味着产品的任何一部分都不能处于“维修”状态超过一天。
- 不要停止开发 - 我们不能仅休假几个星期来重写所有内容。我们公司需要我们。
因此，这些是我们采取的步骤：
首先，将规则设置在适当的位置，并检查自动框架的工作原理。基本上，我们坐在一起，比较了两页的代码相对，有人会说：“这件作品看起来很棒”或“让我们不要使用单线”。请记住，某些规则将很容易达成共识，但有些规则并不多。赞赏妥协的意愿。
接下来，找到尽可能少的拉请请求并在单个规则上运行自动固定的一天。只需运行它，合并它，就完成了。当涉及代码样式的细微差别时，通常是：如果构建它可以正常工作。请记住，当时有拉力请求的人最终会遇到数亿美元的合并冲突。这种方法对我们有效，因此迭代迭代，我们设法达到了900个。许多错误无法自动固定。这让我们有些措手不及，因为我们对下一步该怎么做毫无头绪。
此时，第一个跨越一个人的想法是卷起袖子并全部修复。这个想法拜访了我们天真的思想，我们开始工作。令我们遗憾的是，这种燃烧的热情消失了，因为我们意识到，在代码中出现了很多这些错误，我们没有人参与写作。我们几乎不知道它是如何工作的或为什么起作用的。广泛的测试系统可能已经对此进行了纠正，但是当时我们没有一个测试。您可以冒险和重构此类代码件，只要它们在那里停留很长时间。但是，作为一种不断变化的，不断发展的产品（谁不是？），我们永远无法放心，我们不会在一个月内放弃某些功能或完全重写其背后的逻辑。因此，付出巨大的努力进行重构是有风险的。
总的来说，我们决定坚持童子军规则：始终将您的编辑代码保留得比您发现的更好。我们使用了一个名为suppress ESLint errors 的方便插件，该插件在我们剩下的那些错误中添加了disable-next-line异常，后来，当有人对文件进行更改时，他们可能会花时间修复并删除这些注释。插件留下的规则是前缀的，因此它们与手动禁用规则不同，这有助于我们设定优先级。
第一行说：“该规则自动被禁用。如果看起来很合理，请重新制作我的代码风格协议。如果您在代码审查期间与我见面，请记住，修复我是自愿的。
在此片段中，我们看到了故意禁用规则的示例。这个人说：
在评论期间密切关注我。
最后，让我们再次回顾一下流程：
- 收集您的开发人员并就代码风格达成共识，您所有人都不会遵循
- 配置ESLINT外部库（如果您使用的一个以上的存储库）。
- 在简单规则上运行自动固定，确保项目保持构建和所有测试（您确实有测试，对吗？）。
- 使用AutoPreeFixer插件在本地禁用其余规则，并标记自动禁用。但仍在跟踪您的问题领域。
- 每当您进入代码时，请尝试在与之合作的文件中修复这些前缀的异常。在代码审查期间，赞美您的同事这样做以保持动力的动力;）
还有一种替代方法。从上方遵循步骤1-2，但是
- 将所有规则设置为警告级别。
- 选择一个规则，并将其设置为错误级别。
- 通过让ESLINT自动执行样式或手动重构代码来摆脱所有错误。如果两个选项都不是 - 使用
disable-next-line注释禁用规则，并添加fix-me-laster-if-if-you-can评论，就像我们使用autopreoprefixer插件为我们做的一样。<<<<<<<<<<<<<<<<<<<<<<<<<< /li> - 重复增加错误规则的数量并减少警告规则的数量，直到您完成为止。
这绝对说起来容易做起来容易，我们花了整整一年的时间才能遵循这个计划。
如果听起来很有趣，我们可以通过动手文章进行此操作，介绍如何设置您的NPM软件包库，该库存储Eslint Config。