Eslint团队终于妥协了...

大家好，我卡颂。

你所需要的网站建设服务，我们均能行业靠前的水平为你提供.标准是产品质量的保证，主要从事成都做网站、网站制作、企业网站建设、手机网站制作、网页设计、高端网站设计、网页制作、做网站、建网站。成都创新互联拥有实力坚强的技术研发团队及素养的视觉设计专才。

配置过代码格式化的同学一定纠结过如下问题：Eslint和Prettier都能格式化代码风格，是单用Eslint，还是两个一起用呢？

从今以后，你再也不用纠结这个问题，因为Eslint团队已经妥协了 —— 根据官方博客[1]所说，从v8.53.0起，Eslint中「代码风格相关规则」将被弃用。

有意思的是，造成上述局面的原因并不是技术问题导致的，更多是市场行为。

本文让我们聊聊事情的来龙去脉。

Eslint的崛起

在2013年之前，前端工程师通常使用JSLint或JSHint作为「代码检查器」，用以检测：

代码质量问题

比如：应该避免使用 eval()，应该使用===而不是==...

代码中的错误

比如：未定义的变量、类型转换的问题...

其中，JSLint基于内部实现的JS解析器，对生成的token流（词法单元流）进行分析，检查代码语法。

JSHint是从JSLint派生出来的，他们工作原理类似，但JSHint更灵活 —— 他提供了.jshintrc配置文件方便开发者自定义规则。

上述两个工具都能检查代码，但由于实现原理的限制，没法进行复杂的规则检查。同时，他们对「代码风格」的检查也较少。

在这一时期，「代码风格检查」（比如：缩进、行长度、引号类型、是否在语句末尾使用分号...）主要交给JSCS。

2013年，Eslint问世。他将代码解析为AST并分析：

• 相比于JSHint或JSLint的实现，AST保留了更多代码上下文信息。

所以，Eslint不仅可以进行更复杂的规则校验，还能让开发者以插件的形式自己编写规则。

• 相比于JSCS，Eslint支持「代码自动修复」

所以，Eslint不仅能对代码风格提出建议，还能自动修复「不符合规范的风格」。

更先进的功能，再加上作者身份加持（作者是红宝书作者），使得Eslint逐渐淘汰了上述竞品。

Eslint与Prettier之争

虽然Eslint提供了大量规则，但并不是所有开发者都想配置一套自己的规则集。

慢慢的，一些「Eslint规则集的最佳实践」被提出（比如Airbnb规则[2]、standard规则[3]）。

开发者通常会在这些规则集的基础上再做些个性化修改，组成项目的lint规则集。

这些规则集中，通常包含三类规则：

• 代码质量检查
• 代码错误检查
• 代码风格检查

其中「代码风格检查」通常是非常主观的。如果团队成员的「代码风格检查规则」配置不一样，很影响提交时git diff的可读性。

为了强制规范「代码风格检查」，Prettier出现了。这是一款「固执己见」的代码风格格式化工具，他集成了一套代码风格，并且可配置程度不高。

「可配置程度不高」是一把双刃剑，一方面，他能强制规范团队成员的代码风格。

但另一方面，如果想对代码风格做些个性化设置，Prettier很有可能不支持。

举个例子（来自为什么我不使用 Prettier中的例子），Prettier中通过printWidth属性配置「一行可以显示的字符数」，超过就会折行。

有时候我们并不需要「超过某个字符数就折行」，因为在Git Diff时，折行会破坏Diff信息的可读性：

然而遗憾的是，Prettier并没有提供配置关闭这一行为。

基于上述原因，出现了两种解决方案：

方案1  Eslint与Prettier配合使用

其中Eslint负责代码质量、错误检查，Prettier负责代码风格检查。优点是能够满足代码质量、风格检查。缺点是：

• Eslint与Prettier规则可能冲突，配置成本高。
• 代码风格检查的可配置性低（Prettier配置性低）。

方案2 只使用Eslint

使用「代码风格相关规则的集合」，比如@stylistic/eslint-plugin-js[4]管理代码风格。再使用其他规则管理代码质量。

这种方式优点明显 —— 可配置性高，且配置简单（只需要配置Eslint）。

显然，方案2是优于方案1的。既然如此，Eslint团队为什么要弃用所有「代码风格相关规则」呢？

Eslint团队的妥协

设想一下，每当出现新的语言特性，与该特性相关的规则包括：

• 少量的代码质量相关规则
• 少量的代码错误相关规则
• 各种奇怪的代码风格规则

显然前两者的优先级、重要性都高于第三者。如果说，在Eslint成长初期，为了收割JSCS的用户，Eslint必须实现所有「JSCS支持的代码风格规则」，此时实现各种代码风格规则是必要的。

但今时今日，Eslint早已成为JS领域「代码检查器」的老大，不需要再为了市场份额努力满足社区的一切需要。况且，有些时候，考虑「规则冲突」以及「一致性」，有些需求甚至无法满足。

规则冲突

最理想的情况，所有核心规则都能很好地相互配合，这意味着没有两个规则应该标记同一个问题，也不会有任何两个核心规则给出相互冲突的建议。

当核心规则少于30条时，这很容易。但对于越来越多的规则，这很难做到。

一致性问题

ESLint规则之间是无法互相访问的。这意味着我们会遇到无法正确修复错误的问题，因为信息可能位于另一个规则中。

举个例子，如果自动修复需要添加新的代码行，就需要知道文件是如何缩进的，以便应用正确的修复。但是，规则indent控制ESLint的缩进，这意味着其他规则需要在不缩进的情况下应用修复，然后相信indent规则将在后续传递中修复缩进。

总结

ESLint从v8.53.0起，将弃用「代码风格相关规则」。这么做主要是因为继续维护「代码风格相关规则」对核心团队来说，投入产出比太低。

试想一下，核心团队花费大力气解决问题（规则冲突、一致性问题），推出新的「代码风格规则」，开发者会感谢Eslint核心团队的付出么？

不会的，这些「代码风格规则」会被集成到规则集中，并被冠以「某种开发理念」兜售给开发者（比如Airbnb规范）。

实际收获名利的是站在台前的「宣传开发理念的团队」，而背后辛苦干活的Eslint核心团队往往被忽略了，换你你乐意么？

参考资料

[1]官方博客:https://eslint.org/blog/2023/10/deprecating-formatting-rules/。

[2]Airbnb规则:https://airbnb.io/javascript/。

[3]standard规则:https://standardjs.com/。

[4]@stylistic/eslint-plugin-js:https://www.npmjs.com/package/@stylistic/eslint-plugin-js。

文章名称：Eslint团队终于妥协了...
网站URL：http://www.shufengxianlan.com/qtweb/news2/99702.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联