选项
Prettier 附带了一些格式选项。
¥Prettier ships with a handful of format options.
要了解更多关于 Prettier 在选项上的立场 - 请参阅 选项哲学。
¥To learn more about Prettier’s stance on options – see the Option Philosophy.
如果你更改任何选项,建议通过 配置文件 进行。这样 Prettier CLI、编辑器集成 和其他工具就知道你使用了哪些选项。
¥If you change any options, it’s recommended to do it via a configuration file. This way the Prettier CLI, editor integrations and other tooling knows what options you use.
实验三元组
¥Experimental Ternaries
在 Prettier 的 新的三进制格式 成为默认行为之前尝试一下。
¥Try prettier's new ternary formatting before it becomes the default behavior.
有效选项:
¥Valid options:
true
- 使用奇怪的三元组,在条件后面加上问号。¥
true
- Use curious ternaries, with the question mark after the condition.false
- 保留三元组的默认行为;将问号与结果保持在同一行。¥
false
- Retain the default behavior of ternaries; keep question marks on the same line as the consequent.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --experimental-ternaries | experimentalTernaries: <bool> |
打印宽度
¥Print Width
指定打印机将换行的行长。
¥Specify the line length that the printer will wrap on.
为了便于阅读,我们建议不要使用超过 80 个字符:
¥For readability we recommend against using more than 80 characters:
在代码样式指南中,最大行长度规则通常设置为 100 或 120。然而,当人类编写代码时,他们不会努力达到每一行的最大列数。开发者经常使用空格来分隔长行以提高可读性。实际上,平均行长度通常远低于最大值。
¥In code styleguides, maximum line length rules are often set to 100 or 120. However, when humans write code, they don’t strive to reach the maximum number of columns on every line. Developers often use whitespace to break up long lines for readability. In practice, the average line length often ends up well below the maximum.
Prettier 的 printWidth 选项的工作方式不同。这不是硬性允许的行长度上限。这是一种向 Prettier 大致说明你希望线路多长的方式。Prettier 会制作更短和更长的行,但一般会努力满足指定的 printWidth。
¥Prettier’s printWidth option does not work the same way. It is not the hard upper allowed line length limit. It is a way to say to Prettier roughly how long you’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified printWidth.
请记住,计算机是愚蠢的。你需要明确地告诉他们该做什么,而人类可以做出自己的(隐含的)判断,例如何时断线。
¥Remember, computers are dumb. You need to explicitly tell them what to do, while humans can make their own (implicit) judgements, for example on when to break a line.
换句话说,不要尝试像使用 ESLint 的 max-len 一样使用 printWidth ——它们不一样。max-len 只是表示允许的最大行长度,而不是通常首选的长度 - 这是 printWidth 指定的。
¥In other words, don’t try to use printWidth as if it was ESLint’s max-len – they’re not the same. max-len just says what the maximum allowed line length is, but not what the generally preferred length is – which is what printWidth specifies.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
80 | --print-width <int> | printWidth: <int> |
在 .editorconfig
档 中设置 max_line_length
将配置 Prettier 的打印宽度,除非被覆盖。
¥Setting max_line_length
in an .editorconfig
file will configure Prettier’s print width, unless overridden.
(如果你不想在格式化 Markdown 时换行,你可以设置 散文封装 选项来禁用它。)
¥(If you don’t want line wrapping when formatting Markdown, you can set the Prose Wrap option to disable it.)
标签宽度
¥Tab Width
指定每个缩进级别的空格数。
¥Specify the number of spaces per indentation-level.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
2 | --tab-width <int> | tabWidth: <int> |
在 .editorconfig
档 中设置 indent_size
或 tab_width
将配置 Prettier 的标签宽度,除非被覆盖。
¥Setting indent_size
or tab_width
in an .editorconfig
file will configure Prettier’s tab width, unless overridden.
选项卡
¥Tabs
用制表符而不是空格缩进行。
¥Indent lines with tabs instead of spaces.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --use-tabs | useTabs: <bool> |
在 .editorconfig
档 中设置 indent_style
将配置 Prettier 的选项卡使用,除非被覆盖。
¥Setting indent_style
in an .editorconfig
file will configure Prettier’s tab usage, unless overridden.
(制表符将用于缩进,但 Prettier 使用空格来对齐事物,例如在三元组中。这种行为称为 SmartTabs。)
¥(Tabs will be used for indentation but Prettier uses spaces to align things, such as in ternaries. This behavior is known as SmartTabs.)
分号
¥Semicolons
在语句末尾打印分号。
¥Print semicolons at the ends of statements.
有效选项:
¥Valid options:
true
- 在每个语句的末尾添加一个分号。¥
true
- Add a semicolon at the end of every statement.false
- 只在 可能会引入 ASI 故障 的行首添加分号。¥
false
- Only add semicolons at the beginning of lines that may introduce ASI failures.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
true | --no-semi | semi: <bool> |
引号
¥Quotes
使用单引号而不是双引号。
¥Use single quotes instead of double quotes.
注意:
¥Notes:
JSX 引号忽略此选项 – 请参阅 jsx-single-quote。
¥JSX quotes ignore this option – see jsx-single-quote.
如果引号的数量超过另一个引号,则使用较少的引号来格式化字符串 - 示例:
"I'm double quoted"
导致"I'm double quoted"
,"This \"example\" is single quoted"
导致'This "example" is single quoted'
。¥If the number of quotes outweighs the other quote, the quote which is less used will be used to format the string - Example:
"I'm double quoted"
results in"I'm double quoted"
and"This \"example\" is single quoted"
results in'This "example" is single quoted'
.
有关详细信息,请参阅 字符串基本原理。
¥See the strings rationale for more information.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --single-quote | singleQuote: <bool> |
引号属性
¥Quote Props
引用对象中的属性时更改。
¥Change when properties in objects are quoted.
有效选项:
¥Valid options:
"as-needed"
- 仅在需要时在对象属性周围添加引号。¥
"as-needed"
- Only add quotes around object properties where required."consistent"
- 如果一个对象中至少有一个属性需要引号,请引用所有属性。¥
"consistent"
- If at least one property in an object requires quotes, quote all properties."preserve"
- 尊重对象属性中引号的输入使用。¥
"preserve"
- Respect the input use of quotes in object properties.
默认 | CLI 覆盖 | API 覆盖 | ||||
---|---|---|---|---|---|---|
"as-needed" | --quote-props <as-needed\ | consistent\ | preserve> | quoteProps: "<as-needed\ | consistent\ | preserve>" |
请注意,Prettier 从不在 Angular 表达式、TypeScript 和 Flow 中取消引用数字属性名称,因为字符串和数字键之间的区别在这些语言中很重要。看:Angular、TypeScript、Flow。此外,Prettier 不会取消对 Vue 的数字属性的引用(参见 issue)。
¥Note that Prettier never unquotes numeric property names in Angular expressions, TypeScript, and Flow because the distinction between string and numeric keys is significant in these languages. See: Angular, TypeScript, Flow. Also Prettier doesn’t unquote numeric properties for Vue (see the issue about that).
JSX 行情
¥JSX Quotes
在 JSX 中使用单引号而不是双引号。
¥Use single quotes instead of double quotes in JSX.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --jsx-single-quote | jsxSingleQuote: <bool> |
尾随逗号
¥Trailing Commas
v3.0.0 中默认值从 es5
更改为 all
¥Default value changed from es5
to all
in v3.0.0
在多行逗号分隔的语法结构中尽可能打印尾随逗号。(例如,单行数组永远不会有尾随逗号。)
¥Print trailing commas wherever possible in multi-line comma-separated syntactic structures. (A single-line array, for example, never gets trailing commas.)
有效选项:
¥Valid options:
"all"
- 尽可能在尾随逗号(包括 函数参数和调用)。要运行,以这种方式格式化的 JavaScript 代码需要一个支持 ES2017(Node.js 8+ 或现代浏览器)或 下层编译 的引擎。这还会在 TypeScript 的类型参数中启用尾随逗号(自 2018 年 1 月发布的 TypeScript 2.7 起支持)。¥
"all"
- Trailing commas wherever possible (including function parameters and calls). To run, JavaScript code formatted this way needs an engine that supports ES2017 (Node.js 8+ or a modern browser) or downlevel compilation. This also enables trailing commas in type parameters in TypeScript (supported since TypeScript 2.7 released in January 2018)."es5"
- 在 ES5 中有效的尾随逗号(对象、数组等)。TypeScript 和 Flow 中类型参数中的尾随逗号。¥
"es5"
- Trailing commas where valid in ES5 (objects, arrays, etc.). Trailing commas in type parameters in TypeScript and Flow."none"
- 没有尾随逗号。¥
"none"
- No trailing commas.
默认 | CLI 覆盖 | API 覆盖 | ||||
---|---|---|---|---|---|---|
"all" | --trailing-comma <all\ | es5\ | none> | trailingComma: "<all\ | es5\ | none>" |
括号空格
¥Bracket Spacing
打印对象字面量中括号之间的空格。
¥Print spaces between brackets in object literals.
有效选项:
¥Valid options:
true
- 示例:{ foo: bar }
。¥
true
- Example:{ foo: bar }
.false
- 示例:{foo: bar}
。¥
false
- Example:{foo: bar}
.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
true | --no-bracket-spacing | bracketSpacing: <bool> |
括号行
¥Bracket Line
将多行 HTML(HTML、JSX、Vue、Angular)元素的 >
放在最后一行的末尾,而不是单独放在下一行(不适用于自关闭元素)。
¥Put the >
of a multi-line HTML (HTML, JSX, Vue, Angular) element at the end of the last line instead of being alone on the next line (does not apply to self closing elements).
有效选项:
¥Valid options:
true
- 示例:¥
true
- Example:
<button
className="prettier-class"
id="prettier-id"
onClick={this.handleClick}>
Click Here
</button>
false
- 示例:¥
false
- Example:
<button
className="prettier-class"
id="prettier-id"
onClick={this.handleClick}
>
Click Here
</button>
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --bracket-same-line | bracketSameLine: <bool> |
[弃用] JSX 括号
¥[Deprecated] JSX Brackets
此选项在 v2.4.0 中已被弃用,请改用 --bracket-same-line
¥This option has been deprecated in v2.4.0, use --bracket-same-line instead
将多行 JSX 元素的 >
放在最后一行的末尾,而不是单独放在下一行(不适用于自闭合元素)。
¥Put the >
of a multi-line JSX element at the end of the last line instead of being alone on the next line (does not apply to self closing elements).
有效选项:
¥Valid options:
true
- 示例:¥
true
- Example:
<button
className="prettier-class"
id="prettier-id"
onClick={this.handleClick}>
Click Here
</button>
false
- 示例:¥
false
- Example:
<button
className="prettier-class"
id="prettier-id"
onClick={this.handleClick}
>
Click Here
</button>
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --jsx-bracket-same-line | jsxBracketSameLine: <bool> |
箭头函数括号
¥Arrow Function Parentheses
在 v1.9.0 中首次可用,在 v2.0.0 中默认值从 avoid
更改为 always
¥First available in v1.9.0, default value changed from avoid
to always
in v2.0.0
在唯一的箭头函数参数周围包含括号。
¥Include parentheses around a sole arrow function parameter.
有效选项:
¥Valid options:
"always"
- 始终包括父级。示例:(x) => x
¥
"always"
- Always include parens. Example:(x) => x
"avoid"
- 尽可能省略括号。示例:x => x
¥
"avoid"
- Omit parens when possible. Example:x => x
默认 | CLI 覆盖 | API 覆盖 | ||
---|---|---|---|---|
"always" | --arrow-parens <always\ | avoid> | arrowParens: "<always\ | avoid>" |
乍一看,避免使用括号似乎是更好的选择,因为视觉干扰更少。然而,当 Prettier 移除括号时,添加类型注释、额外参数或默认值以及进行其他更改变得更加困难。在编辑真实代码库时,一致使用括号可提供更好的开发者体验,这证明了该选项的默认值。
¥At first glance, avoiding parentheses may look like a better choice because of less visual noise. However, when Prettier removes parentheses, it becomes harder to add type annotations, extra arguments or default values as well as making other changes. Consistent use of parentheses provides a better developer experience when editing real codebases, which justifies the default value for the option.
范围
¥Range
仅格式化文件的一部分。
¥Format only a segment of a file.
这两个选项可用于格式化以给定字符偏移量开始和结束的代码(分别为包含和排除)。范围将扩大:
¥These two options can be used to format code starting and ending at a given character offset (inclusive and exclusive, respectively). The range will extend:
向后返回到包含所选语句的第一行的开头。
¥Backwards to the start of the first line containing the selected statement.
转发到所选语句的末尾。
¥Forwards to the end of the selected statement.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
0 | --range-start <int> | rangeStart: <int> |
Infinity | --range-end <int> | rangeEnd: <int> |
解析器
¥Parser
指定要使用的解析器。
¥Specify which parser to use.
Prettier 自动从输入文件路径推断解析器,因此你不必更改此设置。
¥Prettier automatically infers the parser from the input file path, so you shouldn’t have to change this setting.
babel
和 flow
解析器都支持相同的 JavaScript 功能集(包括 Flow 类型注释)。它们在某些边缘情况下可能会有所不同,因此如果你遇到其中一种情况,你可以尝试 flow
而不是 babel
。几乎同样适用于 typescript
和 babel-ts
。babel-ts
可能支持 TypeScript 尚不支持的 JavaScript 功能(提案),但它在涉及无效代码时更宽松,并且比 typescript
解析器更少经过实战测试。
¥Both the babel
and flow
parsers support the same set of JavaScript features (including Flow type annotations). They might differ in some edge cases, so if you run into one of those you can try flow
instead of babel
. Almost the same applies to typescript
and babel-ts
. babel-ts
might support JavaScript features (proposals) not yet supported by TypeScript, but it’s less permissive when it comes to invalid code and less battle-tested than the typescript
parser.
有效选项:
¥Valid options:
"babel"
(通过 @babel/parser)在 v1.16.0 之前命名为"babylon"
¥
"babel"
(via @babel/parser) Named"babylon"
until v1.16.0"babel-flow"
(与"babel"
相同,但显式启用 Flow 解析以避免歧义)首先在 v1.16.0 中可用¥
"babel-flow"
(same as"babel"
but enables Flow parsing explicitly to avoid ambiguity) First available in v1.16.0"babel-ts"
(类似于"typescript"
但使用 Babel 及其 TypeScript 插件)首先在 v2.0.0 中可用¥
"babel-ts"
(similar to"typescript"
but uses Babel and its TypeScript plugin) First available in v2.0.0"flow"
(来自 flow-parser)¥
"flow"
(via flow-parser)"typescript"
(通过 @typescript-eslint/typescript-estree)首先在 v1.4.0 中可用¥
"typescript"
(via @typescript-eslint/typescript-estree) First available in v1.4.0"espree"
(通过 espree)首先在 v2.2.0 中可用¥
"espree"
(via espree) First available in v2.2.0"meriyah"
(通过 meriyah)首先在 v2.2.0 中可用¥
"meriyah"
(via meriyah) First available in v2.2.0"acorn"
(通过 acorn)首先在 v2.6.0 中可用¥
"acorn"
(via acorn) First available in v2.6.0"css"
(通过 postcss)首先在 v1.7.1 中提供¥
"css"
(via postcss) First available in v1.7.1"scss"
(通过 postcss-scss)首先在 v1.7.1 中提供¥
"scss"
(via postcss-scss) First available in v1.7.1"less"
(通过 postcss-less)首先在 v1.7.1 中提供¥
"less"
(via postcss-less) First available in v1.7.1"json"
(通过 @babel/parser 解析表达式)首先在 v1.5.0 中可用¥
"json"
(via @babel/parser parseExpression) First available in v1.5.0"json5"
(与"json"
相同的解析器,但输出为 json5)首先在 v1.13.0 中可用¥
"json5"
(same parser as"json"
, but outputs as json5) First available in v1.13.0"jsonc"
(与"json"
相同的解析器,但输出为 "带注释的 JSON")首先在 v3.2.0 中可用¥
"jsonc"
(same parser as"json"
, but outputs as "JSON with Comments") First available in v3.2.0"json-stringify"
(与"json"
相同的解析器,但输出类似于JSON.stringify
)首先在 v1.13.0 中可用¥
"json-stringify"
(same parser as"json"
, but outputs likeJSON.stringify
) First available in v1.13.0"graphql"
(通过 graphql/language)首先在 v1.5.0 中可用¥
"graphql"
(via graphql/language) First available in v1.5.0"markdown"
(通过 remark-parse)首先在 v1.8.0 中可用¥
"markdown"
(via remark-parse) First available in v1.8.0"mdx"
(通过 remark-parse 和 @mdx-js/mdx)首先在 v1.15.0 中可用¥
"mdx"
(via remark-parse and @mdx-js/mdx) First available in v1.15.0"html"
(通过 angular-html-parser)首先在 1.15.0 中可用¥
"html"
(via angular-html-parser) First available in 1.15.0"vue"
(与"html"
相同的解析器,但也格式化特定于 vue 的语法)首先在 1.10.0 中可用¥
"vue"
(same parser as"html"
, but also formats vue-specific syntax) First available in 1.10.0"angular"
(与"html"
相同的解析器,但也通过 angular-estree-parser 格式化角度特定的语法)首先在 1.15.0 中可用¥
"angular"
(same parser as"html"
, but also formats angular-specific syntax via angular-estree-parser) First available in 1.15.0"lwc"
(与"html"
相同的解析器,但也为不带引号的模板属性格式化 LWC 特定语法)首先在 1.17.0 中可用¥
"lwc"
(same parser as"html"
, but also formats LWC-specific syntax for unquoted template attributes) First available in 1.17.0"yaml"
(通过 yaml 和 yaml-unist-parser)首先在 1.14.0 中可用¥
"yaml"
(via yaml and yaml-unist-parser) First available in 1.14.0
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
没有任何 | --parser <string> | parser: "<string>" |
注意:在 v1.13.0 之前,默认值为 "babylon"
。
¥Note: the default value was "babylon"
until v1.13.0.
注意:自定义解析器 API 已在 v3.0.0 中删除。使用 插件 代替 (如何迁移)。
¥Note: the Custom parser API has been removed in v3.0.0. Use plugins instead (how to migrate).
文件路径
¥File Path
指定用于推断要使用哪个解析器的文件名。
¥Specify the file name to use to infer which parser to use.
例如,以下将使用 CSS 解析器:
¥For example, the following will use the CSS parser:
cat foo | prettier --stdin-filepath foo.css
此选项仅在 CLI 和 API 中有用。在配置文件中使用它没有意义。
¥This option is only useful in the CLI and API. It doesn’t make sense to use it in a configuration file.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
没有任何 | --stdin-filepath <string> | filepath: "<string>" |
要求语用
¥Require Pragma
在 v1.7.0 中首次可用
¥First available in v1.7.0
Prettier 可以限制自己只格式化在文件顶部包含特殊注释(称为 pragma)的文件。这在逐渐将大型、未格式化的代码库过渡到 Prettier 时非常有用。
¥Prettier can restrict itself to only format files that contain a special comment, called a pragma, at the top of the file. This is very useful when gradually transitioning large, unformatted codebases to Prettier.
当提供 --require-pragma
时,将格式化以下列作为其第一个注释的文件:
¥A file with the following as its first comment will be formatted when --require-pragma
is supplied:
/**
* @prettier
*/
或者
¥or
/**
* @format
*/
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --require-pragma | requirePragma: <bool> |
插入编译指示
¥Insert Pragma
在 v1.8.0 中首次可用
¥First available in v1.8.0
Prettier 可以在文件顶部插入一个特殊的 @format
标记,指定该文件已使用 Prettier 格式化。这在与 --require-pragma
选项一起使用时效果很好。如果文件顶部已经有一个文档块,则此选项将使用 @format
标记向其添加换行符。
¥Prettier can insert a special @format
marker at the top of files specifying that the file has been formatted with Prettier. This works well when used in tandem with the --require-pragma
option. If there is already a docblock at the top of the file then this option will add a newline to it with the @format
marker.
请注意,“串联”并不意味着“同时”。两个选项同时使用时,--require-pragma
优先,--insert-pragma
被忽略。这个想法是,在大型代码库中逐步采用 Prettier 期间,参与转换过程的开发者使用 --insert-pragma
,而 --require-pragma
则由团队的其他成员使用,自动化工具仅处理已经转换的文件。该功能的灵感来自 Facebook 的 采用策略。
¥Note that “in tandem” doesn’t mean “at the same time”. When the two options are used simultaneously, --require-pragma
has priority, so --insert-pragma
is ignored. The idea is that during an incremental adoption of Prettier in a big codebase, the developers participating in the transition process use --insert-pragma
whereas --require-pragma
is used by the rest of the team and automated tooling to process only files already transitioned. The feature has been inspired by Facebook’s adoption strategy.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --insert-pragma | insertPragma: <bool> |
散文封装
¥Prose Wrap
在 v1.8.2 中首次可用
¥First available in v1.8.2
默认情况下,Prettier 不会更改 Markdown 文本中的封装,因为某些服务使用对换行敏感的渲染器,例如 GitHub 注释和 BitBucket。要让 Prettier 将换行到打印宽度,请将此选项更改为 "always"。如果你想让 Prettier 强制所有的散文块在一行上并依赖于编辑器/查看器软封装,你可以使用 "never"
。
¥By default, Prettier will not change wrapping in markdown text since some services use a linebreak-sensitive renderer, e.g. GitHub comments and BitBucket. To have Prettier wrap prose to the print width, change this option to "always". If you want Prettier to force all prose blocks to be on a single line and rely on editor/viewer soft wrapping instead, you can use "never"
.
有效选项:
¥Valid options:
"always"
- 如果散文超出打印宽度,则将其换行。¥
"always"
- Wrap prose if it exceeds the print width."never"
- 将每一段散文拆成一行。¥
"never"
- Un-wrap each block of prose into one line."preserve"
- 什么都不做,让散文保持原样。在 v1.9.0 中首次可用¥
"preserve"
- Do nothing, leave prose as-is. First available in v1.9.0
默认 | CLI 覆盖 | API 覆盖 | ||||
---|---|---|---|---|---|---|
"preserve" | --prose-wrap <always\ | never\ | preserve> | proseWrap: "<always\ | never\ | preserve>" |
HTML 空白敏感度
¥HTML Whitespace Sensitivity
首先在 v1.15.0 中可用。首次可用于 2.3.0 中的 Handlebars
¥First available in v1.15.0. First available for Handlebars in 2.3.0
指定 HTML、Vue、Angular 和 Handlebars 的全局空白敏感度。有关详细信息,请参阅 空白敏感格式。
¥Specify the global whitespace sensitivity for HTML, Vue, Angular, and Handlebars. See whitespace-sensitive formatting for more info.
有效选项:
¥Valid options:
"css"
- 遵守 CSSdisplay
属性的默认值。对于与strict
相同处理的 Handlebars。¥
"css"
- Respect the default value of CSSdisplay
property. For Handlebars treated same asstrict
."strict"
- 所有标签周围的空白(或缺少空白)被认为是重要的。¥
"strict"
- Whitespace (or the lack of it) around all tags is considered significant."ignore"
- 所有标签周围的空格(或缺少空格)被认为是无关紧要的。¥
"ignore"
- Whitespace (or the lack of it) around all tags is considered insignificant.
默认 | CLI 覆盖 | API 覆盖 | ||||
---|---|---|---|---|---|---|
"css" | --html-whitespace-sensitivity <css\ | strict\ | ignore> | htmlWhitespaceSensitivity: "<css\ | strict\ | ignore>" |
Vue 文件脚本和样式标签缩进
¥Vue files script and style tags indentation
在 v1.19.0 中首次可用
¥First available in v1.19.0
Vue 文件中 <script>
和 <style>
标签内的代码是否缩进。
¥Whether or not to indent the code inside <script>
and <style>
tags in Vue files.
有效选项:
¥Valid options:
false
- 不要在 Vue 文件中缩进脚本和样式标签。¥
false
- Do not indent script and style tags in Vue files.true
- 在 Vue 文件中缩进脚本和样式标签。¥
true
- Indent script and style tags in Vue files.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --vue-indent-script-and-style | vueIndentScriptAndStyle: <bool> |
行结束
¥End of Line
在 v1.15.0 中首次可用,在 v2.0.0 中默认值从 auto
更改为 lf
¥First available in v1.15.0, default value changed from auto
to lf
in v2.0.0
由于历史原因,文本文件中存在两种常见的行结束方式。即 \n
(或 LF
用于换行)和 \r\n
(或 CRLF
用于回车 + 换行)。前者在 Linux 和 macOS 上很常见,而后者在 Windows 上很普遍。一些细节解释了为什么它是如此 可以在维基百科上找到。
¥For historical reasons, there exist two common flavors of line endings in text files.
That is \n
(or LF
for Line Feed) and \r\n
(or CRLF
for Carriage Return + Line Feed).
The former is common on Linux and macOS, while the latter is prevalent on Windows.
Some details explaining why it is so can be found on Wikipedia.
当人们在不同操作系统上协作处理一个项目时,很容易在共享的 git 存储库中以混合行结尾结束。Windows 用户也可能不小心将先前提交的文件中的行结尾从 LF
更改为 CRLF
。这样做会产生一个很大的 git diff
,从而使文件 (git blame
) 的逐行历史更难探索。
¥When people collaborate on a project from different operating systems, it becomes easy to end up with mixed line endings in a shared git repository.
It is also possible for Windows users to accidentally change line endings in a previously committed file from LF
to CRLF
.
Doing so produces a large git diff
and thus makes the line-by-line history for a file (git blame
) harder to explore.
如果你想确保你的整个 git 存储库仅包含 Prettier 覆盖的文件中的 Linux 样式行结尾:
¥If you want to make sure that your entire git repository only contains Linux-style line endings in files covered by Prettier:
确保 Prettier 的
endOfLine
选项设置为lf
(这是自 v2.0.0 以来的默认值)¥Ensure Prettier’s
endOfLine
option is set tolf
(this is a default value since v2.0.0)配置将运行 Prettier 的 预提交钩子
¥Configure a pre-commit hook that will run Prettier
使用
--check
标志 配置 Prettier 以在你的 CI 管道中运行。如果你使用 Travis CI,请在.travis.yml
中将autocrlf
选项 设置为input
。¥Configure Prettier to run in your CI pipeline using
--check
flag. If you use Travis CI, set theautocrlf
option toinput
in.travis.yml
.将
* text=auto eol=lf
添加到 repo 的.gitattributes
文件中。你可能需要要求 Windows 用户在此更改后重新克隆你的存储库,以确保 git 在结账时没有将LF
转换为CRLF
。¥Add
* text=auto eol=lf
to the repo’s.gitattributes
file. You may need to ask Windows users to re-clone your repo after this change to ensure git has not convertedLF
toCRLF
on checkout.
使用 \n
(LF
) 时,所有操作系统中的所有现代文本编辑器都能够正确显示行尾。但是,旧版本的 Windows 记事本会在视觉上将这些行压缩为一行,因为它们只能处理 \r\n
(CRLF
)。
¥All modern text editors in all operating systems are able to correctly display line endings when \n
(LF
) is used.
However, old versions of Notepad for Windows will visually squash such lines into one as they can only deal with \r\n
(CRLF
).
有效选项:
¥Valid options:
"lf"
- 仅换行 (\n
),在 Linux 和 macOS 以及 git repos 中很常见¥
"lf"
– Line Feed only (\n
), common on Linux and macOS as well as inside git repos"crlf"
- 回车 + 换行字符 (\r\n
),在 Windows 上很常见¥
"crlf"
- Carriage Return + Line Feed characters (\r\n
), common on Windows"cr"
- 仅回车字符 (\r
),很少使用¥
"cr"
- Carriage Return character only (\r
), used very rarely"auto"
- 维护现有的行结尾(一个文件中的混合值通过查看第一行之后使用的内容来规范化)¥
"auto"
- Maintain existing line endings (mixed values within one file are normalised by looking at what’s used after the first line)
默认 | CLI 覆盖 | API 覆盖 | ||||||
---|---|---|---|---|---|---|---|---|
"lf" | --end-of-line <lf\ | crlf\ | cr\ | auto> | endOfLine: "<lf\ | crlf\ | cr\ | auto>" |
在 .editorconfig
档 中设置 end_of_line
将配置 Prettier 的行尾使用,除非被覆盖。
¥Setting end_of_line
in an .editorconfig
file will configure Prettier’s end of line usage, unless overridden.
嵌入式语言格式化
¥Embedded Language Formatting
在 v2.1.0 中首次可用
¥First available in v2.1.0
控制 Prettier 是否格式化嵌入在文件中的引用代码。
¥Control whether Prettier formats quoted code embedded in the file.
当 Prettier 识别出你放置了一些代码的情况时,它知道如何在另一个文件的字符串中格式化,比如在 JavaScript 中带有名为 html
的标记的标记模板或在 Markdown 中的代码块中,它会默认尝试 格式化该代码。
¥When Prettier identifies cases where it looks like you've placed some code it knows how to format within a string in another file, like in a tagged template in JavaScript with a tag named html
or in code blocks in Markdown, it will by default try to format that code.
有时这种行为是不可取的,特别是在你可能不希望将字符串解释为代码的情况下。此选项允许你在默认行为 (auto
) 和完全禁用此功能 (off
) 之间切换。
¥Sometimes this behavior is undesirable, particularly in cases where you might not have intended the string to be interpreted as code. This option allows you to switch between the default behavior (auto
) and disabling this feature entirely (off
).
有效选项:
¥Valid options:
"auto"
- 如果 Prettier 可以自动识别嵌入代码,则格式化嵌入代码。¥
"auto"
– Format embedded code if Prettier can automatically identify it."off"
- 永远不要自动格式化嵌入代码。¥
"off"
- Never automatically format embedded code.
默认 | CLI 覆盖 | API 覆盖 | ||
---|---|---|---|---|
"auto" | --embedded-language-formatting=<off\ | auto> | embeddedLanguageFormatting: "<off\ | auto>" |
每行单个属性
¥Single Attribute Per Line
在 v2.6.0 中首次可用
¥First available in v2.6.0
在 HTML、Vue 和 JSX 中每行强制执行单个属性。
¥Enforce single attribute per line in HTML, Vue and JSX.
有效选项:
¥Valid options:
false
- 不要强制每行使用一个属性。¥
false
- Do not enforce single attribute per line.true
- 每行强制执行单个属性。¥
true
- Enforce single attribute per line.
默认 | CLI 覆盖 | API 覆盖 |
---|---|---|
false | --single-attribute-per-line | singleAttributePerLine: <bool> |