选项理念
Prettier 有一些选项是因为历史原因。但我们不会再添加更多选项了。
继续阅读以了解更多信息。
Prettier 不是一个“万能”代码格式化工具，试图以任何你想要的方式打印你的代码。它是有主见的。引用为什么选择 Prettier？页面
采用 Prettier 最大的原因是停止所有关于代码风格的持续争论。
然而，Prettier 的选项越多，它就越偏离上述目标。关于代码风格的争论变成了关于使用哪些 Prettier 选项的争论。格式化战争重新燃起：“哪些选项值更好？为什么？我们做出了正确的选择吗？”
而且选项带来的代价不仅仅是这些。要了解更多关于选项缺点的信息，请查看关于抵制添加配置的问题，该问题比任何选项请求问题都获得更多👍。
那么为什么会有任何选项呢？
- 在 Prettier 的初期添加了一些选项，以使其能够起步。🚀
- 在“强烈需求”后添加了一些选项。🤔
- 有些选项是为了兼容性而添加的。👍
更容易被理解的选项包括
--trailing-comma es5允许你在大多数环境中使用尾随逗号，而无需进行转译（尾随函数逗号在 ES2017 中添加）。--prose-wrap对于支持各种奇特的 Markdown 渲染器非常重要。--html-whitespace-sensitivity由于 HTML 不幸的空格规则而需要。--end-of-line使团队更容易将 CRLF 拒之其 Git 仓库之外。--quote-props对于 Google Closure Compiler 的高级用法很重要。
但其他选项事后看来很难被理解：--arrow-parens、--jsx-single-quote、--bracket-same-line 和 --no-bracket-spacing 不是我们乐于拥有的选项类型。它们在团队中导致了很多无谓的争论，我们对此表示歉意。这些选项现在很难移除，它们作为历史遗留物存在，不应该成为添加更多选项的理由（“如果这些选项存在，为什么这个选项不行？”）。
长期以来，我们一直保持选项请求开放，以便让讨论进行下去并收集反馈。这些年来我们学到的是，衡量需求真的很难。Prettier 的使用量大幅增长。过去所谓的“强烈需求”现在已经不那么强烈了。GitHub 反馈和 Twitter 投票变得不再具有代表性。所有沉默的用户呢？添加“仅仅一个”选项看起来很容易。但我们应该在哪里停止？多少算太多？即使添加了“最后一个选项”，问题跟踪器中也总会有一个“热门问题”。
然而，停止的时候到了。现在 Prettier 已经足够成熟，并且我们看到它被如此多的组织和项目采用，研究阶段已经结束。我们有足够的信心得出结论，Prettier 已经达到了选项集应该“冻结”的程度。不再接受选项请求。感谢所有参与这一艰难旅程的人。
请注意，由于选项请求超出了 Prettier 的范围，因此它们将被关闭而不会进行讨论。对于保留输入格式元素（例如换行符）的请求也适用相同规则，因为这不过是伪装成选项的另一种形式，并带有“真正”选项的所有缺点。在某些情况下，由于技术需要（例如兼容性），添加选项可能是不可避免的，但对于与格式相关的选项，这是最终决定。