例如，采取以下代码：
foo(arg1, arg2, arg3, arg4);
它适宜一行，以是它会保持原样。但是，我们都碰着过这种情形：
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
溘然之间，我们之前调用函数的格式就崩溃了，由于它太长了。Prettier 会为你做这样的事情：
foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());
Prettier在全体代码库中逼迫实行同等的代码样式（即不会影响 AST 的代码格式），由于它忽略了原始样式通过解析它并利用其自己的规则重新打印解析的 AST，这些规则采取最大行长度考虑到，必要时包装代码。
基本事理精确性
Prettier 的第一个哀求是输出与格式化之前具有完备相同行为的有效代码。请报告 Prettier 未能遵照这些精确性规则的任何代码——这是一个须要修复的缺点！
字符串
双引号还是单引号？Prettier 选择逃生次数最少的那个。"It's gettin' better!"，不是'It\'s gettin\' better!'。如果平局或字符串不包含任何引号，Prettier 默认利用双引号（但可以通过singleQuote选项变动）。
JSX 有自己的引号选项：jsxSingleQuote。JSX 源于 HTML，个中属性引号的紧张用场是双引号。纵然源代码利用单引号，浏览器开拓工具也始终利用双引号显示 HTML，从而遵照此约定。一个单独的选项许可对 JS 利用单引号，对 "HTML" (JSX) 利用双引号。
空行事实证明，空行很难自动天生。Prettier 采取的方法是保留原始源代码中的空行。还有两个附加规则：
Prettier 将多个空行折叠成一个空行。块（和全体文件）开头和结尾的空行被删除。（不过，文件总是以一个换行符结尾。）多行工具
默认情形下，Prettier 的打印算法在适宜的情形下将表达式打印在一行上。但是，工具在 JavaScript 中用于许多不同的事情，有时如果它们保持多行，它确实有助于提高可读性。例如，拜会工具列表、嵌套配置、样式表和键控方法。我们无法为所有这些情形找到一个好的规则，以是如果{原始源代码中的第一个键和第一个键之间有换行符，Prettier 会保持工具多行。这样做的结果是长的单行工具会自动展开，但短的多行工具永久不会折叠。提示：如果您有一个多行工具，您想合并成一行：
const user = { name: "John Doe", age: 30,};
您须要做的便是在以下内容之后删除换行符{：
const user = { name: "John Doe", age: 30};
然后运行 Prettier：
const user = { name: "John Doe", age: 30 };
如果您想再次利用多行，请在之后添加换行符{：
const user = { name: "John Doe", age: 30 };
然后运行 Prettier：
const user = { name: "John Doe", age: 30,};
JSX
当涉及 JSX 时，Prettier 打印的内容与其他 JS 比较略有不同：
function greet(user) { return user ? `Welcome back, ${user.name}!` : "Greetings, traveler! Sign up today!";}function Greet({ user }) { return ( <div> {user ? ( <p>Welcome back, {user.name}!</p> ) : ( <p>Greetings, traveler! Sign up today!</p> )} </div> );}
首先，很多人已经将他们的 JSX 包裹在括号中，尤其是在return语句中。Prettier 遵照了这种常见的风格。
其次，备用格式使编辑 JSX 更随意马虎。很随意马虎留下分号。与普通 JS 不同，JSX 中剩余的分号终极会以纯文本形式显示在您的页面上。
<div> <p>Greetings, traveler! Sign up today!</p>; {/ <-- Oops! /}</div>
注释
说到评论的内容，Prettier 真的无能为力。注释可以包含从散文到注释掉的代码和 ASCII 图表的所有内容。由于它们可以包含任何东西，Prettier 不知道如何格式化或包装它们。以是他们保持原样。唯一的例外是 JSDoc 样式的注释（每行以 a 开头的块注释），Prettier 可以修复它的缩进。
然后是在哪里放置评论的问题。事实证明，这是一个非常困难的问题。Prettier 尽最大努力将您的评论大致保留在原处，但这并非易事，由于评论险些可以放置在任何地方。
常日，将注开释在自己的行而不是行尾时，您会得到最好的结果。更喜好// eslint-disable-next-line.// eslint-disable-line
请把稳，由于 Prettier 将表达式分成多行，因此有时须要手动移动“魔术注释”，例如eslint-disable-next-lineand 。$FlowFixMe
想象一下这段代码：// eslint-disable-next-line no-evalconst result = safeToEval ? eval(input) : fallback(input);
然后你须要添加另一个条件：
// eslint-disable-next-line no-evalconst result = safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);
Prettier 会将上述内容变为：
// eslint-disable-next-line no-evalconst result = safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);
这意味着该eslint-disable-next-line评论不再有效。在这种情形下，您须要移动评论：
const result = // eslint-disable-next-line no-eval safeToEval && settings.allowNativeEval ? eval(input) : fallback(input);
如果可能，更喜好在行范围（例如eslint-disableand eslint-enable）或语句级别（例如/ istanbul ignore next /）上操作的注释，它们乃至更安全。可以利用 来禁止利用eslint-disable-line和eslint-disable-next-line评论eslint-plugin-eslint-comments。
安装Prettier首先，在本地安装 Prettier：
npm install --save-dev --save-exact prettier
然后，创建一个空配置文件，让编辑器和其他工具知道您正在利用 Prettier：
echo {}> .prettierrc.json
接下来，创建一个.prettierignore文件，让 Prettier CLI 和编辑器知道哪些文件不能格式化。这是一个例子：
# Ignore artifacts:buildcoverage
现在，利用 Prettier 格式化所有文件：
npx prettier --write .
prettier --write .非常适宜格式化所有内容，但对付大型项目可能须要一点韶光。你可以运行prettier --write app/格式化某个目录，或者prettier --write app/components/Button.js格式化某个文件。或者利用glob likeprettier --write "app//.test.js"格式化目录中的所有测试（请参阅fast-glob以理解支持的 glob 语法）。
如果您有 CI 设置，请在个中运行以下命令以确保每个人都运行 Prettier。这避免了合并冲突和其他协作问题！
npx prettier --check .
--check就像--write，但只检讨文件是否已经格式化，而不是覆盖它们。prettier --write并且prettier --check是运行 Prettier 最常用的方法。
与 Linter 集成Linter 常日不仅包含代码质量规则，还包含样式规则。利用 Prettier 时，大多数风格规则都是不必要的，但更糟糕的是——它们可能与 Prettier 冲突！
利用 Prettier 办理代码格式问题，利用 linter 办理代码质量问题，如Prettier vs. Linters中所述。
在 Internet 上搜索 Prettier 和您的 linter 时，您可能会找到更多干系的项目。这些常日不被推举，但在某些情形下可能很有用。
首先，我们有一些插件可以让你像运行 linter 规则一样运行 Prettier：
eslint Prettierstylelint-prettier这些插件在 Prettier 刚推出时特殊有用。通过在你的 linter 中运行 Prettier，你不必设置任何新的根本举动步伐，你可以为 linter 重新利用你的编辑器集成。但是现在你可以运行prettier --check .并且大多数编辑器都有 Prettier 支持。
这些插件的缺陷是：
你终极会在你的编辑器中看到很多赤色的波浪线，这很烦人。Prettier 该当让你忘却格式化——而不是面对它！它们比直接运行 Prettier 慢。它们仍旧是事情可能中断的间接层。
—END—
开源协议：MIT license
开源地址：https://github.com/prettier/prettier
