website/blog/2020-03-21-2.0.0.md
Better defaults, a better CLI and better heuristics. Oh, and TypeScript 3.8.
After a long and careful consideration, we decided to change the default values for the trailingComma, arrowParens, and endOfLine options. We made the CLI more intuitive. And we've finally dropped support for Node versions older than 10, which had grown to become a huge maintenance hassle and an obstacle for contributors. Read below in details.
Previously, any method call chain of length three or longer would be automatically broken into multiple lines. The new heuristic is based on the complexity of the call arguments in the chain, rather than simply on the chain's length. Now, if chained method calls have arguments which aren't easy to understand at a glance (e.g. functions or deeply-nested objects), the chain is broken. Otherwise, they're allowed to remain on one line. See prior issues #3197, #4765, #1565 and #4125 for context and examples.
To get best results, make sure your value for the printWidth option isn't too high.
// Prettier 1.19
if (
foo
.one()
.two()
.three() ===
bar
.four()
.five()
.six()
) {
// ...
}
// Prettier 2.0
if (foo.one().two().three() === bar.four().five().six()) {
// ...
}
Prettier has been trying not to corrupt these JSDoc type assertions since v1.6.0, with mixed results. As type checking based on JSDoc becomes increasingly common, we've been getting new bug reports about this syntax. The bugs were tricky because the required parentheses around the expression weren't part of the AST, so Prettier didn't have a good way to detect their presence.
Finally, we used the createParenthesizedExpressions option of the Babel parser to represent parentheses in the AST using non-standard nodes. This helped fix all the reported bugs.
Consequently, Prettier won't recognize JSDoc type casts if the flow or typescript parser is used, but this is reasonable as this syntax makes little sense in Flow and TypeScript files.
// Input
const nestedAssertions = /** @type {MyType} */
(/** @type {unknown} */
(x));
// Prettier 1.19
const nestedAssertions /** @type {MyType} */ /** @type {unknown} */ = x;
// Prettier 2.0
const nestedAssertions = /** @type {MyType} */ (/** @type {unknown} */ (x));
Reference documentation for this syntax: Closure Compiler, TypeScript (with --checkJs).
Prettier now supports the new syntax added in TypeScript 3.8:
Since file names in Linux can contain almost any characters, strings like foo*.js and [bar].css are valid file names. Previously, if the user needed to format a file named [bar].css, a glob escaping syntax had to be used: prettier "\[bar].css" (this one doesn't work on Windows, where backslashes are treated as path separators) or prettier "[[]bar].css". Because of this, important use cases were broken. E.g. lint-staged passes absolute paths and knows nothing about the escaping syntax. Now, when Prettier CLI gets a glob, it first tries to resolve it as a literal file name.
. (#7660 by @thorn0)It's finally possible to run prettier --write . to format all supported files in the current directory and its subdirectories.
Directory names can be mixed with file names and glob patterns (e.g. prettier src "test/*.spec.js" foo.js).
Also, the order in which files are processed has changed. Previously, all the files were sorted alphabetically before formatting. Now, their order corresponds to the order of the specified paths. For each path, the list of resolved files is sorted, but the full sorting of the resulting combined list isn't done anymore.
There are also changes in how Prettier CLI reports errors if passed patterns don't match any files. Previously, Prettier CLI printed a "No matching files" error if it couldn't find any files at all—for all the patterns together, not for an individual pattern. In Prettier 2.0, the CLI also prints such errors for individual patterns.
Previously, configuration overrides weren't applied to files whose name had a leading dot.
The minimal required Node version now is 10.13.0. For our contributors, this means there is no need anymore to jump through hoops to make tests pass on Node 4.
trailingComma to es5 (#6963 by @fisker)Before version 2.0, Prettier was avoiding trailing commas by default where possible. This made the resulting JavaScript compatible with now very old environments such as IE8, but implied some missed opportunities.
Prettier has included an option to configure trailing commas since its early days, and an initiative to change the default value has been out there for over three years.
Finally, the default value becomes es5 instead of none in Prettier v2.0.
If the old behavior is still preferred, please configure Prettier with { "trailingComma": "none" }.
There is a possibility that the default value will change to all (meaning even more trailing commas) in a future major version of Prettier as the JavaScript ecosystem further matures.
prettier.util (#6993 by @fisker)prettier.util.mapDoc has been removed.
Use prettier.doc.utils.mapDoc instead.
prettier.util.isNextLineEmpty has been updated.
Use isNextLineEmpty(text, node, locEnd) instead of isNextLineEmpty(text, node, options).
prettier.util.isPreviousLineEmpty has been updated.
Use isPreviousLineEmpty(text, node, locStart) instead of isPreviousLineEmpty(text, node, options).
prettier.util.getNextNonSpaceNonCommentCharacterIndex has been updated.
Use getNextNonSpaceNonCommentCharacterIndex(text, node, locEnd) instead of getNextNonSpaceNonCommentCharacterIndex(text, node, options).
arrowParens to always (#7430 by @kachkaev)Since version 1.9, Prettier has had an option to always wrap arrow function arguments with parentheses. In version 2.0, this behavior has become the default.
<!-- prettier-ignore -->// Input
const fn = (x) => y => x + y;
// Prettier 1.19
const fn = x => y => x + y;
// Prettier 2.0
const fn = (x) => (y) => x + y;
At first glance, avoiding parentheses in the isolated example above may look like a better choice because it results in less visual noise. However, when Prettier removes parentheses, it becomes harder to add type annotations, extra arguments, default values, or a variety of other things. Consistent use of parentheses provides a better developer experience when editing real codebases, which justifies the change.
You are encouraged to use the new default value, but if the old behavior is still preferred, please configure Prettier with { "arrowParens": "avoid" }.
endOfLine to lf (#7435 by @kachkaev)Early versions of Prettier were formatting all files with the *nix flavor of line endings (\n, also known as LF).
This behavior was changed in #472, which allowed preserving Windows line endings (\r\n, also known as CRLF).
Since Prettier version 1.15, the flavor of line endings has been configurable via the endOfLine option.
The default value was set to auto for backwards compatibility, which meant that Prettier preserved whichever flavor of line endings was already present in a given file.
That meant Prettier converted mixed line endings within one file to what was found at the end of the first line.
However, line endings in separate files could still remain inconsistent.
Besides, contributors on different operating systems could accidentally change line endings in previously committed files and this would be fine with Prettier.
Doing so would produce a large git diff and thus make the line-by-line history for a file (git blame) harder to explore.
You are encouraged to use the new default value for endOfLine, which is now lf.
It may be also worth checking the option docs to ensure your project repository is configured correctly.
This will help you avoid a mix of line endings in the repo and a broken git blame.
If the old behavior is still preferred, please configure Prettier with { "endOfLine": "auto" }.
If you use Travis CI, be aware of the autocrlf option in .travis.yml.
Previously, Prettier searched the file system for plugins on every prettier.format call. Now, search results are cached. The cache can be cleared by calling prettier.clearConfigCache().
useFlowParser (--flow-parser in CLI) has been deprecated since v0.0.10.parser: babylon (renamed to babel in v1.16.0), postcss (renamed to css in v1.7.1), typescript-eslint (an old alias for typescript)proseWrap: true (renamed to always in v1.9.0), false (renamed to never in v1.9.0)trailingComma: true (renamed to es5 in v0.19.0), false (renamed to none in v0.19.0)version parameter of prettier.getSupportInfo (#7620 by @thorn0)Since Prettier 1.8.0, it was possible to pass a version number to prettier.getSupportInfo to get information on the languages, options, etc. supported by previous versions. This interesting but apparently not very useful API kept causing maintenance problems and has been removed in Prettier 2.0.0.
function keyword (#3903 by @j-f1, @josephfrazier, @sosukesuzuki, @thorn0; #7516 by @bakkot)Previously, a space would be added after the function keyword in function declarations, but not in function expressions. Now, for consistency, a space is always added after the function keyword. The only exception is generator declarations where function* is treated as a whole word.
// Prettier 1.19
const identity = function(value) {
return value;
};
function identity(value) {
return value;
}
const f = function<T>(value: T) {};
const g = function*() {};
// Prettier 2.0
const identity = function (value) {
return value;
};
function identity(value) {
return value;
}
const f = function <T>(value: T) {};
const g = function* () {};
// Input
loop1:
//test
const i = 3;
// Prettier 1.19 (first output)
loop1: //test
const i = 3;
// Prettier 1.19 (second output)
//test
loop1: const i = 3;
// Prettier 2.0 (first and second outputs)
//test
loop1: const i = 3;
// Input
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo || bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo | bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${(foo, bar)}`;
// Prettier 1.19
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo ||
bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo |
bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${(foo,
bar)}`;
// Prettier 2.0
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
foo || bar
}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
foo | bar
}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
(foo, bar)
}`;
// Input
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
(askTrovenaBeenaDependsRowans === 2 || glimseGlyphsHazardNoopsTieTie === 3);
// Prettier 1.19 (first output)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 || glimseGlyphsHazardNoopsTieTie === 3;
// Prettier 1.19 (second output)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 ||
glimseGlyphsHazardNoopsTieTie === 3;
// Prettier 2.0 (first and second outputs)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 ||
glimseGlyphsHazardNoopsTieTie === 3;
throw like return (#7070 by @sosukesuzuki)// Input
function foo() {
throw this.hasPlugin("dynamicImports") && this.lookahead().type === tt.parenLeft.right;
}
// Prettier 1.19
function foo() {
throw this.hasPlugin("dynamicImports") &&
this.lookahead().type === tt.parenLeft.right;
}
// Prettier 2.0
function foo() {
throw (
this.hasPlugin("dynamicImports") &&
this.lookahead().type === tt.parenLeft.right
);
}
// Input
const foo = (number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20) ?
kochabCooieGameOnOboleUnweave : annularCooeedSplicesWalksWayWay)
? anodyneCondosMalateOverateRetinol : averredBathersBoxroomBuggyNurl;
// Prettier 1.19
const foo = (number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20)
? kochabCooieGameOnOboleUnweave
: annularCooeedSplicesWalksWayWay)
? anodyneCondosMalateOverateRetinol
: averredBathersBoxroomBuggyNurl;
// Prettier 2.0
const foo = (
number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20)
? kochabCooieGameOnOboleUnweave
: annularCooeedSplicesWalksWayWay
)
? anodyneCondosMalateOverateRetinol
: averredBathersBoxroomBuggyNurl;
Because decorators modify the line following, splitting a decorator call’s arguments onto multiple lines can obscure the relationship between the decorator and its intended target, producing less-readable code. Therefore, the function composition logic introduced in #6033 has been changed to exclude decorator calls.
<!-- prettier-ignore -->// Input
export class Item {
@OneToOne(() => Thing, x => x.item)
thing!: Thing;
}
// Prettier 1.19
export class Item {
@OneToOne(
() => Thing,
x => x.item,
)
thing!: Thing;
}
// Prettier 2.0
export class Item {
@OneToOne(() => Thing, x => x.item)
thing!: Thing;
}
return statement with comment (#7140 by @sosukesuzuki)// Input
return // comment
;
// Prettier 1.19
return // comment;
// Prettier 2.0
return; // comment
Prettier had been adding newlines for every HTML template string, which could lead to unexpected whitespace in rendered HTML.
This doesn't happen anymore unless --html-whitespace-sensitivity ignore option is given.
// Input
html`<div>`;
html` <span>TEXT</span> `;
// Prettier 1.19
html`
<div></div>
`;
html`
<span>TEXT</span>
`;
// Prettier 2.0
html`<div></div>`;
html` <span>TEXT</span> `;
// Input
function* f() {
yield <div>generator</div>;
}
// Prettier 1.19
function* f() {
yield (<div>generator</div>);
}
// Prettier 2.0
function* f() {
yield <div>generator</div>;
}
Omitting these parentheses makes the code invalid.
<!-- prettier-ignore -->// Input
export default (1, 2);
// Prettier 1.19
export default 1, 2;
// Prettier 2.0
export default (1, 2);
// Input
(foo?.bar)();
new (foo?.bar)();
// Prettier 1.19
foo?.bar();
new foo?.bar();
// Prettier 2.0
(foo?.bar)();
new (foo?.bar)();
undefined in parentheses in conditional expressions within JSX (#7504 by @fisker)Previously, parentheses were added around any expression except null. Now, undefined is excluded too.
// Input
foo ? <span>loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx</span> :
undefined
foo ? <span>loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx</span> :
null
// Prettier 1.19
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : (
undefined
);
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : null;
// Prettier 2.0
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : undefined;
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : null;
// Input
const foo = /* comments */
bar;
// Prettier 1.19
const foo /* comments */ = bar;
// Prettier 2.0
const foo = /* comments */ bar;
A new value for the parser option has been added: babel-ts, which makes use of Babel’s TypeScript plugin. The babel-ts parser supports JavaScript features not yet supported by TypeScript (ECMAScript proposals, e.g. private methods and accessors), but it's less permissive when it comes to error recovery and less battle-tested than the typescript parser. While Babel’s TypeScript plugin is quite mature, ASTs produced by the two parsers aren't 100% compatible. We tried to take the discrepancies into account, but there are most likely still cases where code gets formatted differently or even incorrectly. We call upon you, our users, to help us find such cases. If you see them, please raise issues. In the long run, this will help with unifying the AST format in future versions of the parsers and thus contribute to a better, more solid JavaScript parser ecosystem.
// Input
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<
Collections.Parts.PrintedCircuitBoardAssembly["attributes"] & undefined
> => {};
// Prettier 1.19
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<Collections.Parts.PrintedCircuitBoardAssembly["attributes"] &
undefined> => {};
// Prettier 2.0
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<
Collections.Parts.PrintedCircuitBoardAssembly["attributes"] & undefined
> => {};
Another fix related to error recovery. Should come in handy to those who migrate from Flow to TypeScript.
<!-- prettier-ignore -->// Input
function fromFlow(arg: ?Maybe) {}
// Prettier 1.19
Error: unknown type: "TSJSDocNullableType"
// Prettier 2.0
function fromFlow(arg: ?Maybe) {}
// Input
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[],
];
// Prettier 1.19
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[],
];
// Prettier 2.0
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[]
];
This could happen with code written in the no-semicolon style if the statement after the variable declaration was prefixed with a semicolon to avoid ASI issues.
<!-- prettier-ignore -->// Input
const foo = () => {
return
}
// foo
;[1,2,3].forEach(bar)
// Prettier 1.19
const foo = () => {
return;
};
// foo
[1, 2, 3].forEach(bar);
// Prettier 2.0
const foo = () => {
return;
};
// foo
[1, 2, 3].forEach(bar);
// Input
type f1 = (
currentRequest: {a: number},
// TODO this is a very very very very long comment that makes it go > 80 columns
) => number;
// Prettier 1.19
type f1 = (currentRequest: {
a: number;
}) => // TODO this is a very very very very long comment that makes it go > 80 columns
number;
// Prettier 2.0
type f1 = (
currentRequest: { a: number }
// TODO this is a very very very very long comment that makes it go > 80 columns
) => number;
// Input
interface foo1 {
bar1/* foo */ (/* baz */) // bat
bar2/* foo */ ? /* bar */ (/* baz */) /* bat */;
bar3/* foo */ (/* baz */) /* bat */
bar4/* foo */ ? /* bar */ (bar: /* baz */ string): /* bat */ string;
/* foo */ (/* bar */): /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new /* bar */ (a: /* baz */ string): /* bat */ string
/* foo */ new /* bar */ (/* baz */): /* bat */ string
}
type foo7 = /* foo */ (/* bar */) /* baz */ => void
type foo8 = /* foo */ (a: /* bar */ string) /* baz */ => void
let foo9: new /* foo */ (/* bar */) /* baz */ => string;
let foo10: new /* foo */ (a: /* bar */ string) /* baz */ => string;
// Prettier 1.19
interface foo1 {
bar1 /* foo */ /* baz */(); // bat
bar2 /* foo */ /* bar */ /* baz */ /* bat */?();
bar3 /* foo */ /* baz */() /* bat */;
bar4 /* foo */?(/* bar */ bar: /* baz */ string): /* bat */ string;
/* foo */ (): /* bar */ /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new (/* bar */ a: /* baz */ string): /* bat */ string;
/* foo */ new (): /* bar */ /* baz */ /* bat */ string;
}
type foo7 = /* foo */ () => /* bar */ /* baz */ void;
type foo8 = /* foo */ (a: /* bar */ string) => /* baz */ void;
let foo9: new () => /* foo */ /* bar */ /* baz */ string;
let foo10: new (/* foo */ a: /* bar */ string) => /* baz */ string;
// Prettier 2.0
interface foo1 {
bar1 /* foo */(/* baz */); // bat
bar2 /* foo */ /* bar */?(/* baz */) /* bat */;
bar3 /* foo */(/* baz */) /* bat */;
bar4 /* foo */?(/* bar */ bar: /* baz */ string): /* bat */ string;
/* foo */ (/* bar */): /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new (/* bar */ a: /* baz */ string): /* bat */ string;
/* foo */ new (/* baz */): /* bar */ /* bat */ string;
}
type foo7 = /* foo */ (/* bar */) => /* baz */ void;
type foo8 = /* foo */ (a: /* bar */ string) => /* baz */ void;
let foo9: new (/* bar */) => /* foo */ /* baz */ string;
let foo10: new (/* foo */ a: /* bar */ string) => /* baz */ string;
// Input
abstract class Test {
abstract foo12 /* foo */ (a: /* bar */ string): /* baz */ void
abstract foo13 /* foo */ (/* bar */) /* baz */
}
// Prettier 1.19
Error: Comment "foo" was not printed. Please report this error!
// Prettier 2.0
abstract class Test {
abstract foo12 /* foo */(a: /* bar */ string): /* baz */ void;
abstract foo13 /* foo */(/* bar */); /* baz */
}
// Input
type A = { [key in B] };
// Prettier 1.19
type A = { [key in B]: };
// Prettier 2.0
type A = { [key in B] };
Even though index signatures without type annotations or with multiple parameters aren't valid TypeScript, the TypeScript parser supports this syntax. In line with the previous error recovery efforts, Prettier now makes sure its output still can be parsed in these cases. Previous versions produced unparsable code.
<!-- prettier-ignore -->// Input
type A = { [key: string] };
type B = { [a: string, b: string]: string; };
// Prettier 1.19
type A = { [key: string]: };
type B = { [a: stringb: string]: string };
// Prettier 2.0
type A = { [key: string] };
type B = { [a: string, b: string]: string };
// Input
const a: T</* comment */> = 1;
// Prettier 1.19
Error: Comment "comment" was not printed. Please report this error!
// Prettier 2.0
const a: T</* comment */> = 1;
symbol (#7472 by @fisker)A new AST node type was introduced in [email protected], now it's recognized.
<!-- prettier-ignore -->// Input
const x: symbol = Symbol();
// Prettier after updating Flow, but without this fix
Error: unknown type: "SymbolTypeAnnotation"
// Prettier 2.0
const x: symbol = Symbol();
// Input
/* @flow */
@decorator4
class Foo {
@decorator1
method1() {}
@decorator2
@decorator3
method2() {}
}
// Prettier 1.19
SyntaxError: Unexpected token `@`, expected the token `class` (2:1)
// Prettier 2.0
/* @flow */
@decorator4
class Foo {
@decorator1
method1() {}
@decorator2
@decorator3
method2() {}
}
// Input
class Foo {
#privateProp: number;
}
// Prettier 1.19
class Foo {
privateProp: number;
}
// Prettier 2.0
class Foo {
#privateProp: number;
}
Previously, Prettier already preserved casing of unknown element names, but it did lowercase names of HTML elements. This caused issues when CSS was applied to a case-sensitive document and there was an element with the same name as in HTML, which is the case in NativeScript. Prettier now always preserves original casing.
<!-- prettier-ignore -->/* Input */
Label {
}
/* Prettier 1.19 */
label {
}
/* Prettier 2.0 */
Label {
}
Previously, when trailingComma set to es5, an extra comma was added after last comment in an SCSS map.
// Input
$my-map: (
'foo': 1, // Comment
'bar': 2, // Comment
);
// Prettier 1.19
$my-map: (
"foo": 1,
// Comment
"bar": 2,
// Comment,
);
// Prettier 2.0
$my-map: (
"foo": 1,
// Comment
"bar": 2,
// Comment
);
// Input
a {
background-image: url($test-path + 'static/test.jpg');
}
// Prettier 1.19
a {
background-image: url($test-path+"static/test.jpg");
}
// Prettier 2.0
a {
background-image: url($test-path + "static/test.jpg");
}
postcss-less (#6981 by @fisker, #7021 by @evilebottnawi, @thorn0)each is supported now (#5653).!important was being moved out of mixin call parameters (#3544).::before was broken in mixin call parameters (#5791).pre tags caused bad formatting of following closing tag (#5959 by @selvazhagan)<!-- Input -->
<details>
<pre>
<!-- TEST -->
</pre></details>
<!-- Prettier 1.19 -->
<details>
<pre>
<!-- TEST -->
</pre></details</details
>
<!-- Prettier 2.0 -->
<details>
<pre>
<!-- TEST -->
</pre>
</details>
In HTML5, colons don't have any special meaning in tag names. Previously, Prettier treated them the XML way, as namespace prefix delimiters, but no more. In practice, this means that tags whose ancestors have colons in their names are now treated as usual HTML tags: if they're known standard tags, their names can be lowercased and assumptions can be made about their whitespace sensitivity; custom elements whose names are unknown to Prettier retain the casing of their names and, if --html-whitespace-sensitivity is set to css, are treated as inline.
<!-- Input -->
<with:colon>
<div> looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block </div>
<DIV> block </DIV><DIV> block </DIV> <DIV> block </DIV><div> block </div><div> block </div>
<pre> pre pr
e</pre>
<textarea> pre-wrap pr
e-wrap </textarea>
<span> looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline </span>
<span> inline </span><span> inline </span> <span> inline </span><span> inline </span>
</with:colon>
<!-- Prettier 1.19 -->
<with:colon>
<div>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block
</div>
<DIV> block </DIV><DIV> block </DIV> <DIV> block </DIV><div> block </div
><div> block </div>
<pre> pre pr e</pre>
<textarea> pre-wrap pr e-wrap </textarea>
<span>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline
</span>
<span> inline </span><span> inline </span> <span> inline </span
><span> inline </span>
</with:colon>
<!-- Prettier 2.0 -->
<with:colon>
<div>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block
</div>
<div>block</div>
<div>block</div>
<div>block</div>
<div>block</div>
<div>block</div>
<pre>
pre pr
e</pre
>
<textarea>
pre-wrap pr
e-wrap </textarea
>
<span>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline
</span>
<span> inline </span><span> inline </span> <span> inline </span
><span> inline </span>
</with:colon>
<!-- Input -->
<div><span>
<
<!-- Prettier 1.19 -->
TypeError: Cannot read property 'start' of null
<!-- Prettier 2.0 -->
<div><span> < </span></div>
<!-- Input -->
<!-- Prettier 1.19 -->
Error: Mixed descriptor in srcset is not supported
<!-- Prettier 2.0 -->
pre tag (#7392 by @fisker)<!-- Input -->
<pre>
</pre>
<pre><hr></pre>
<!-- Prettier 1.19 -->
TypeError: Cannot read property 'start' of null
<!-- Prettier 2.0 -->
<pre>
</pre>
<pre><hr /></pre>
<!-- Input -->
<span><input type="checkbox"/> </span>
<span><span><input type="checkbox"/></span></span>
<span><input type="checkbox"/></span>
<!-- Prettier 1.19 -->
<span><input type="checkbox" /> </span>
<span
><span><input type="checkbox"/></span
></span>
<span><input type="checkbox"/></span>
<!-- Prettier 2.0 -->
<span><input type="checkbox" /> </span>
<span
><span><input type="checkbox" /></span
></span>
<span><input type="checkbox" /></span>
table tags (#7461 by @ikatyang)<!-- Input -->
<table><tr>
</tr>
</table><div>Should not insert empty line before this div</div>
<!-- Prettier 1.19 -->
<table>
<tr></tr>
</table>
<div>Should not insert empty line before this div</div>
<!-- Prettier 2.0 -->
<table>
<tr></tr>
</table>
<div>Should not insert empty line before this div</div>
class attribute (#7555 by @fisker)<!-- Input -->
<div class=" foo
bar baz"></div>
<div class="
another element with so many classes
even can not fit one line
really a lot and lot of classes
"></div>
<!-- Prettier 1.19 -->
<div
class=" foo
bar baz"
></div>
<div
class="
another element with so many classes
even can not fit one line
really a lot and lot of classes
"
></div>
<!-- Prettier 2.0 -->
<div class="foo bar baz"></div>
<div
class="another element with so many classes even can not fit one line really a lot and lot of classes"
></div>
style attribute (#7556 by @fisker)<!-- Input -->
<div style=" color : red;
display :inline ">
</div>
<div style=" color : red;
display :inline; height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0; ">
</div>
<!-- Prettier 1.19 -->
<div
style=" color : red;
display :inline "
></div>
<div
style=" color : red;
display :inline; height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0; "
></div>
<!-- Prettier 2.0 -->
<div style="color: red; display: inline;"></div>
<div
style="
color: red;
display: inline;
height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
"
></div>
<!-- prettier ignore --> for text (#7654 by @graemeworthy)Previously, it worked only for tags. Useful for protecting various macros and pre-processor commands from being corrupted by formatting.
<!-- prettier-ignore --><!-- Input -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably generated by some script.
<!-- Prettier 1.19 -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably
generated by some script.
<!-- Prettier 2.0 -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably generated by some script.
<!-- Input -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats | Tigers |
| ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- | ---- | ------ |
| 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |
<!-- Prettier 1.19 -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats |
Tigers | | ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- |
---- | ------ | | 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |
<!-- Prettier 2.0 -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats | Tigers |
| ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- | ---- | ------ |
| 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |
<!-- Input -->
<script lang="jsx">
export default {
data: () => ({
message: 'hello with jsx'
}),
render(h) {
return <div>{this.message}</div>
}
}
</script>
<!-- Prettier 1.19 -->
<script lang="jsx">
export default {
data: () => ({
message: 'hello with jsx'
}),
render(h) {
return <div>{this.message}</div>
}
}
</script>
<!-- Prettier 2.0 -->
<script lang="jsx">
export default {
data: () => ({
message: "hello with jsx"
}),
render(h) {
return <div>{this.message}</div>;
}
};
</script>
<!-- Input -->
<template>
<MyComponent
:attr1="`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`"
:attr2="'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'"/>
</template>
<!-- Prettier 1.19 -->
<template>
<MyComponent
:attr1="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`
"
:attr2="
'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'
"
/>
</template>
<!-- Prettier 2.0 -->
<template>
<MyComponent
:attr1="`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`"
:attr2="'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'"
/>
</template>
<!-- Input -->
<template>
<MyComponent v-if="
long_long_long_long_long_long_long_condition_1 && long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>
<!-- Prettier 1.19 -->
<template>
<MyComponent
v-if="
long_long_long_long_long_long_long_condition_1 &&
long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>
<!-- Prettier 2.0 -->
<template>
<MyComponent
v-if="
long_long_long_long_long_long_long_condition_1 &&
long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>
While there are some syntax incompatibilities (one-time bindings and the precedence of |) between the expression languages of the old AngularJS and the new Angular, overall the two languages are compatible enough for legacy and hybrid AngularJS-based projects to be able to benefit from using Prettier. Previously, when Prettier formatted AngularJS templates using the Angular parser, it formatted expressions only in interpolations. Now, some of the most used AngularJS directives are formatted too, namely: ng-if, ng-show, ng-hide, ng-class, ng-style.
<!-- Input -->
<div ng-if="$ctrl .shouldShowWarning&&!$ctrl.loading ">Warning!</div>
<!-- Prettier 1.19 -->
<div ng-if="$ctrl .shouldShowWarning&&!$ctrl.loading ">Warning!</div>
<!-- Prettier 2.0 -->
<div ng-if="$ctrl.shouldShowWarning && !$ctrl.loading">Warning!</div>
Prettier 1.19 added support for formatting i18n attributes, but putting the closing quote mark on a new line broke custom ids. This is fixed now.
<!-- prettier-ignore --><!-- Input -->
<div i18n-prop="Special-property|This is a special property with much important information@@MyTextId"
prop="My Text"></div>
<!-- Prettier 1.19 -->
<div
i18n-prop="
Special-property|This is a special property with much important
information@@MyTextId
"
prop="My Text"
></div>
<!-- Prettier 2.0 -->
<div
i18n-prop="
Special-property|This is a special property with much important
information@@MyTextId"
prop="My Text"
></div>
ConcatStatement (#7051 by @dcyriller){{!-- Input --}}
<a href="a-very-long-href-from-a-third-party-marketing-platform{{id}}longer-than-eighty-chars">Link</a>
{{!-- Prettier 1.19 --}}
<a
href="a-very-long-href-from-a-third-party-marketing-platform
{{id}}
longer-than-eighty-chars"
>
Link
</a>
{{!-- Prettier 2.0 --}}
<a
href="a-very-long-href-from-a-third-party-marketing-platform{{id}}longer-than-eighty-chars"
>
Link
</a>
and
<!-- prettier-ignore -->{{!-- Input --}}
<div class="hello {{if goodbye true}} {{if goodbye false}} {{if goodbye true}} {{if goodbye false}} {{if goodbye true}}">
Hello
</div>
{{!-- Prettier 1.19 --}}
<div
class="hello
{{if goodbye true}}
{{if goodbye false}}
{{if goodbye true}}
{{if goodbye false}}
{{if goodbye true}}"
>
Hello
</div>
{{!-- Prettier 2.0 --}}
<div
class="hello {{if goodbye true}} {{if goodbye false}} {{if goodbye true}} {{if
goodbye
false
}} {{if goodbye true}}"
>
Hello
</div>
{{!-- Input --}}
<GlimmerComponent @progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}} />
{{!-- Prettier 1.19 --}}
<GlimmerComponent
@progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue
}}
/>
{{!-- Prettier 2.0 --}}
<GlimmerComponent
@progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}}
/>
MustacheStatement printing (#7157 by @dcyriller){{!-- Input --}}
<p>Hi here is your name, as it will be displayed {{firstName}} {{lastName}} , welcome!</p>
{{!-- Prettier 1.19 --}}
<p>
Hi here is your name, as it will be displayed {{firstName}} {{lastName
}} , welcome!
</p>
{{!-- Prettier 2.0 --}}
<p>
Hi here is your name, as it will be displayed {{firstName}} {{
lastName
}} , welcome!
</p>
prettier-ignore (#7275 by @chadian){{! Input }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This
is="preserved"
/>
{{/my-crazy-component}}
</div>
{{#a-normal-component isRestoredTo = "order" }}
<ThisWillBeNormal backTo = "normal" />
{{/a-normal-component}}
{{! Prettier 1.19 }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This is="preserved" />
{{/my-crazy-component}}
</div>
{{#a-normal-component isRestoredTo="order"}}
<ThisWillBeNormal backTo="normal" />
{{/a-normal-component}}
{{! Prettier 2.0 }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This
is="preserved"
/>
{{/my-crazy-component}}
</div>
{{#a-normal-component isRestoredTo='order'}}
<ThisWillBeNormal backTo='normal' />
{{/a-normal-component}}
<!-- Input -->
<script type="text/x-handlebars-template">
{{component arg1='hey' arg2=(helper this.arg7 this.arg4) arg3=anotherone arg6=this.arg8}}
</script>
<!-- Prettier 1.19 -->
<script type="text/x-handlebars-template">
{{component arg1='hey' arg2=(helper this.arg7 this.arg4) arg3=anotherone arg6=this.arg8}}
</script>
<!-- Prettier 2.0 -->
<script type="text/x-handlebars-template">
{{component
arg1='hey'
arg2=(helper this.arg7 this.arg4)
arg3=anotherone
arg6=this.arg8
}}
</script>
{{!-- Input --}}
<ul class="abc
def">
</ul>
{{!-- Prettier 1.19 --}}
<ul class></ul>
{{!-- Prettier 2.0 --}}
<ul class="abc
def">
</ul>
{{!-- Input --}}
{{~#if bar}}
if1
{{~else~}}
else
{{~/if~}}
{{!-- Prettier 1.19 --}}
{{#if bar}}
if1
{{else}}
else
{{/if}}
{{!-- Prettier 2.0 --}}
{{~#if bar}}
if1
{{~else~}}
else
{{~/if~}}
Even though using a comma to separate multiple implemented interfaces is deprecated syntax, in order to support legacy use cases, Prettier keeps the original separator and doesn't wilfully replace commas with ampersands. Previously, however, this logic contained a bug, so the wrong separator could end up in the output. This is fixed now.
<!-- prettier-ignore --># Input
type Type1 implements A, B
# { & <-- Removing this comment changes the separator in 1.19
{a: a}
type Type2 implements A, B & C{a: a}
# Prettier 1.19
type Type1 implements A & B {
# { & <-- Removing this comment changes the separator in 1.19
a: a
}
type Type2 implements A & B & C {
a: a
}
# Prettier 2.0
type Type1 implements A, B {
# { & <-- Removing this comment changes the separator in 1.19
a: a
}
type Type2 implements A, B & C {
a: a
}
<!-- Input -->
0. List
1. List
2. List
<!-- Prettier 1.19 -->
0. List
1. List
1. List
<!-- Prettier 2.0 -->
0. List
1. List
2. List
Previously, when Prettier formatted an HTML tag placed just after a list item, it would insert indent and break the relationship of open and close tag. Now, Prettier no longer changes anything.
<!-- prettier-ignore --><!-- Input -->
- A list item.
<details><summary>Summary</summary>
<p>
- A list item.
</p>
</details>
- A list item
<blockquote>asdf</blockquote>
<!-- Prettier 1.19 -->
- A list item.
<details><summary>Summary</summary>
<p>
- A list item.
</p>
</details>
- A list item
<blockquote>asdf</blockquote>
<!-- Prettier 2.0 -->
- A list item.
<details><summary>Summary</summary>
<p>
- A list item.
</p>
</details>
- A list item
<blockquote>asdf</blockquote>
<!-- Input -->
Here's a statement[^footnote].
[^footnote]:
Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.
<!-- Prettier 1.19 -->
Here's a statement[^footnote].
[^footnote]:
Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.
<!-- Prettier 2.0 -->
Here's a statement[^footnote].
[^footnote]:
Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.
<!-- Input -->
<>
test <World /> test
</> 123
<!-- Prettier 1.19 -->
<>
test <World /> test
</> 123
<!-- Prettier 2.0 -->
<>
test <World /> test
</> 123
MDX parsing for JSX failed when encountering JSX elements that where not
parsable as HTML, such as <Tag value={{a: 'b'}}>test</Tag>
<!-- Input -->
<Tag value={ {a : 'b' } }>test</ Tag>
<Foo bg={ 'red' } >
<div style={{ display: 'block'} }>
<Bar >hi </Bar>
{ hello }
{ /* another comment */}
</div>
</Foo>
<!-- Prettier 1.19 -->
SyntaxError: Unexpected closing tag "Tag". It may happen when the tag has already been closed by another tag. For more info see https://www.w3.org/TR/html5/syntax.html#closing-elements-that-have-implied-end-tags (1:35)
> 1 | <Tag value={ {a : 'b' } }>test</ Tag>
<!-- Prettier 2.0 -->
<Tag value={{ a: "b" }}>test</Tag>
<Foo bg={"red"}>
<div style={{ display: "block" }}>
<Bar>hi </Bar>
{hello}
</div>
</Foo>
.cjs and .yaml.sed (#7210 by @sosukesuzuki)# Prettier 1.19
$ prettier test.cjs
test.cjs[error] No parser could be inferred for file: test.cjs
# Prettier 2.0
$ prettier test.cjs
"use strict";
console.log("Hello, World!");
--ignore-path when prettier executes from a subdirectory (#7588 by @heylookltsme)Changes the filename used when filtering ignored files to be relative to the
--ignore-path, if present, rather than the current working directory.
--stdin (#7668 by @thorn0)This CLI flag, never properly documented, was supposed to make Prettier CLI read input from stdin, but Prettier CLI does so anyway when not given any file paths or glob patterns. So the flag was redundant. Now that it's been removed, if you use this flag in your commands, you'll see a warning: "Ignored unknown option". This warning is just information. It doesn't prevent the command from doing what it should do and doesn't affect the exit code.