EditorConfig vs. Eslint vs. Prettier:是否值得使用它们?

PBa*_*Jen 31 formatting code-formatting eslint editorconfig prettier

我正在尝试设置一些工具来帮助维护多个开发人员使用的代码库的一致性.是否有必要一起使用EditorConfig,ESlint和Prettier?据我所知,EditorConfig用于设置编码样式/规则,ESlint用于确保代码的格式一致,如果代码不遵循规则则抛出警告,并且更漂亮用于根据规则自动格式化代码.但是,我相信你可以更漂亮地自定义规则,这反过来又完成了EditorConfig的工作.这是真的?用于维护一致代码的最佳工具组合是什么?

Kev*_*ech 61

根据我的经验,最佳组合是3,这就是为什么:

EditorConfig:这可以帮助您的编辑器生成与您的样式指南相似的代码.虽然这对于实现目标并非绝对必要,但如果您始终关注遵循相同编码样式的代码,那就太好了.否则,如果您没有EditorConfig,那么当您键入时,编辑器将自动格式化为代码库的其余部分,这是令人困惑的.当然,如果你设置得更漂亮,它会在它进入你的代码库之前修复它,但是,为什么你要在编写它时以一种格式查看它然后在你去的时候切换它提交?也可以保持一致.

更漂亮:自动格式化您的代码.我喜欢将我的文件设置为提交时进行设置,这样我就不可能提交与我的样式指南不匹配的代码.

ESLint:那你为什么还想要一个linter呢?因为ESLint不仅仅是风格.当你声明你不使用的变量,或者引用一些未定义的东西时,它会在其他一些细节中找到它.因此,虽然与较漂亮的日子相比,它的角色有所减少,但在项目中捕获其他错误仍然很有用.

希望有所帮助!

  • 我不明白为什么我应该同时使用 EditorConfig 和 Prettier。还可以使用 Prettier 在 IDE 中格式化代码。您也可以将 EditorConfig 集成到 CI 工具链中,因此不需要 Prettier。您能更详细地解释一下吗? (5认同)
  • 我赞同@laprof 的评论。不明白为什么不直接使用 Prettier。可以使用更清晰的解释。 (3认同)
  • @laprof,例如,当您使用 VSCode 扩展进行 prettier 时,它会在保存时格式化。当您打字时,它不会格式化以匹配您更漂亮的风格。例如,我使用制表符,如果没有编辑器配置,VSCode 默认为空格,直到我保存,然后它将运行 Prettier。正如我在答案中解释的那样,这并不重要,但保持一致性很好。你完全可以不用编辑器配置,但出于这个原因我更喜欢拥有它。 (3认同)

Has*_*kçe 24

更漂亮

它删除了所有原始样式并确保所有输出的代码符合一致的样式。

  • 它会在编写代码更改您的代码。
  • 例如
    • 使用 Visual Studio Code 编辑器保存
    • 使用类似 CLIprettier --write .

编辑器配置

EditorConfig有助于跨不同编辑器和 IDE 处理同一项目的多个开发人员保持一致的编码风格。

  • 它在编写代码 之前应用您的规则
    • 例如
      • 当您按下 时TAB,会留下四个空格。

ESLint

ESLint静态分析您的代码以快速发现问题。

  • ESLint 发现代码中的问题

总结一下:

  • EditorConfig更改您的编辑器设置
  • Prettier用您的规则更新您的代码,以重塑您的代码
最后:
  • 他们有一些共同的特征,以便做同样的事情。
  • 我也同意KevinBrownTech使用其中三个。尤其是当您与团队合作时。

对于想要深入研究的人来说有用的资源:

另请查看 React 框架的存储库:

在此输入图像描述


Mar*_*o B 10

我会使用EditorConfig(文件~/.editorconfig)和ESLint,但避免Prettier

总长DR

远离 HTML 或其他标记语言的 prettier。这对于阅读和维护来说是一场噩梦,而且你只是为了增加 99% 的时间里不相关的属性的可读性而失去了整体结构的可读性(imo)。Prettier 还迫使您遵守他们的意见,而不是使用您团队同意的格式。

完整说明

Prettier 是一个固执己见的代码格式化程序,可确保一致性(这是一件好事),但它可能有点太过分了。

代码风格是固执己见的,我坚信最好的代码风格是您的团队或组织同意的风格。只需进行讨论并给每个人一个表达意见的机会,您就会拥有更多快乐的开发人员。Prettier 的问题在于,他们直率地将自己的观点强加给你,并且不给你选择关闭那些困扰你的事情。他们缺乏配置选项,并且可能永远不会添加它们,因为这违背了他们希望“停止所有关于样式的持续争论”的选项哲学,只有当每个开发人员都接受相同的样式时,这种情况才会发生。

我个人认为这是不可取的。首先,人们是不同的,想要使用不同的造型。其次,人们使用不同的语言,Prettier 的观点显然在某些语言(如 Java/JavaScript)上比其他语言(如 HTML)效果更好。

Prettier可以通过配置解决所有这些问题,并且真正成为每个人都使用的一种格式化程序,但遗憾的是(imo)他们不想成为一种格式化程序,而是想成为一种代码风格。我并不是说这一切都不好,但他们的愿景可能不适合你。如果您希望自己自由决定代码的外观如何更好,请使用其他格式化程序。

更漂亮的问题

问题:删除精心设置的换行符

对我来说,Prettier 做的最烦人的事情是合并你的行,删除你故意添加的换行符以提高可读性 - 假设你总是希望在第二行中添加辅助功能标签 -> Prettier 不可能做到这一点!如果两行组合起来都适合“打印宽度”,无论您想要什么,它都会将它们折叠成一行!

问题:格式跳转

很容易忘记您在代码中的位置。您正在编写三行代码,按下自动格式化热键,然后突然完全丢失,因为文件已完全重新格式化。对于所有格式化程序来说,这在某种程度上都是正确的,但没有其他格式化程序会如此具有侵入性,并且会为三行代码添加 15 个换行符(请参阅下一点)!

问题:打印宽度

Prettier 使用“打印宽度”设置(请参阅Prettier 选项)来确保行在同一字符周围的某个位置结束。例如,这将分解太长的行,这是所有代码格式化程序都会做的事情。Prettier 以他自己固执己见的方式行事。一个简短的 HTML div,包含两个Angular指令、一些类和一些辅助功能属性:

<div *ngIf="ability?.length > 0 && ! loading" tabindex="0" myCustomDirective class="col-lg responsive-input-wrapper d-flex align-items-center" role="navigation" aria-label="Primary">
Run Code Online (Sandbox Code Playgroud)

现在 Prettier 将其格式化为:

<div
  ngIf="ability?.length > 0 && ! loading"
  tabindex="0"
  myCustomDirective
  class="col-lg responsive-input-wrapper d-flex align-items-center"
  role="navigation"
  aria-label="Primary"
>
Run Code Online (Sandbox Code Playgroud)

这对于它自己来说当然更具可读性。但有几点:编辑 HTML 时,您很少会对所有属性感兴趣。您通常会有一个特定的目标。假设您正在设计某些东西,然后您将扫描代码中的“类”属性,并对整体结构更感兴趣。

Prettier 的特点是:通过所有这些换行符,您可以在屏幕上容纳四个元素!虽然对于这四个元素来说,每个属性本身都具有很高的可读性,但这却以整体结构的可读性为代价

如果您对四个以上的元素感兴趣,您将不得不滚动很多次,这可能会令人难以置信的令人沮丧。对我来说,用 prettier 格式化的 HTML(尤其是他们荒谬的建议行长度仅为 80)非常难以阅读和理解。

大多数其他格式化程序会以不同的方式执行此操作(或让您选择),并且仅在必要时才分割行,因此您只有两行而不是八行。如果没有水平滚动,所有内容仍然可见(我认为我们都认为这是可怕的并且必须避免)。更好的是:明智的开发人员可以考虑在什么上下文中阅读什么是重要的,并且可以提出一个解决方案,将相关内容保持在一致的行上(例如,Angular 属性和指令始终位于第一行等)

这可能看起来像这样:

<div *ngIf="ability?.length > 0 && ! loading"  myCustomDirective
     class="col-lg responsive-input-wrapper d-flex align-items-center"
     tabindex="0" role="navigation" aria-label="Primary">
Run Code Online (Sandbox Code Playgroud)

这似乎是一个很好的中间立场。您只有三行,仍然可以看到大部分整体结构,但属性也具有很好的可读性(特别是 Angular / Style / ARIA 之间的划分)。

但这对于 Prettier 来说是不可能的,因为它会折叠您故意的换行符(请参阅问题 1)或将每个属性写入新行,即使所有三行都适合打印宽度(问题 3)

什么时候使用 Prettier 才有意义

仅当您没有更好的选择时才使用 Prettier。假设这是一个非常异构的环境,就像一个开源项目——世界各地的人们使用不同的环境和 IDE 处理同一件事。在这样的环境中很难解释和实施更明智的代码样式。对于这些情况,Prettier 是一个很好的解决方案,因为在这种情况下您不能依赖 IDE 设置,并且 .editorconfig 有点受限。

但对于您的典型工作项目(大约有 5 个开发人员使用类似的 IDE 和工具),有更好、更灵活的选择,尤其是在格式化 HTML 方面。Editorconfig 是一个很好的起点。更好的是:如果你们都使用相同的工具,则只需签入项目格式化程序,每个人的 IDE 都会使用它。某些 IDE(例如IntelliJ IDEAWebStorm)也可以将格式化程序设置导入/导出为其他 IDE 格式。


api*_*art 7

虽然我认为很明显你需要 eslint 和 prettier,但我实际上认为至少在某些情况下你可以摆脱 editorconfig。

如果您将编辑器设置为使用 prettier 自动格式化代码,那么 prettier 和 editorconfig 之间的唯一区别就是它们使用的规则。

例如,在某些情况下,prettier 可能不会删除尾随的空格,或者它可能具有无法更改的默认规则。

但是,如果您对更漂亮的规则感到满意,并且您的编辑器支持使用更漂亮的自动格式化,我猜您可以删除 editorconfig。


小智 7

这是KevinBrownTech更明确的回应。

例如,当您使用 Visual Studio Code 扩展进行 prettier 时,它 会在 save 时格式化当您打字时,它不会格式化以匹配您的 Prettier 样式。例如,我使用制表符,如果没有 EditorConfig,Visual Studio Code 默认为空格,直到我保存,然后它将运行 Prettier

总之,.editorconfig 的作用是配置您的编辑器,以便您编写的代码已经格式化,而 Prettier 将格式化您已经编写的代码,并且 ESLint 确保您的代码符合其配置中设置的最佳实践或规则。