website/blog/2021-05-09-2.3.0.md
This release focuses on fixing long-standing issues in the JavaScript printer. Be warned that, unfortunately, reformatting a project with the new version might result in quite a big diff. If you don’t use ignoreRevsFile to hide such wholesale changes from git blame, it might be about time.
A remarkable milestone is the long-awaited release of the Ember / Handlebars formatter. It’s supposed to be the last formatter included directly in the core library. In the future, for sustainability, languages should be added only by plugins.
We are grateful to our financial contributors: Salesforce, Indeed, Frontend Masters, Airbnb, Shogun Labs, Skyscanner, Konstantin Pschera, and many others who help us keep going. If you enjoy Prettier and would like to support our work, head to our OpenCollective. Please consider also supporting the projects Prettier depends on, such as typescript-eslint, remark, and Babel.
Most of the changes in this release are thanks to the hard work of Fisker Cheung, Georgii Dolzhykov, and Sosuke Suzuki, along with many other contributors.
And just a reminder, when Prettier is installed or updated, it’s strongly recommended to specify the exact version in package.json: "2.3.0", not "^2.3.0".
Previously, Prettier had a lot of trouble with figuring out how to break lines in assignments. E.g., long right-hand sides often stayed unbroken. Not anymore.
<!-- prettier-ignore -->// Prettier 2.2
aParticularlyLongAndObnoxiousNameForIllustrativePurposes = anotherVeryLongNameForIllustrativePurposes;
aParticularlyLongAndObnoxiousNameForIllustrativePurposes = "a very long string for illustrative purposes"
.length;
someReallyLongThingStoredInAMapWithAReallyBigName[
pageletID
] = _someVariableThatWeAreCheckingForFalsiness
? Date.now() - _someVariableThatWeAreCheckingForFalsiness
: 0;
class x {
private readonly rawConfigFromFile$: BehaviorSubject<any> = new BehaviorSubject(
notRead
);
}
// Prettier 2.3
aParticularlyLongAndObnoxiousNameForIllustrativePurposes =
anotherVeryLongNameForIllustrativePurposes;
aParticularlyLongAndObnoxiousNameForIllustrativePurposes =
"a very long string for illustrative purposes".length;
someReallyLongThingStoredInAMapWithAReallyBigName[pageletID] =
_someVariableThatWeAreCheckingForFalsiness
? Date.now() - _someVariableThatWeAreCheckingForFalsiness
: 0;
class x {
private readonly rawConfigFromFile$: BehaviorSubject<any> =
new BehaviorSubject(notRead);
}
Line breaks after short property names in object literals often look unnatural. Even when such a line break yields a line length benefit of 1 or 2 characters, it rarely looks justified. Prettier 2.3 avoids line breaks after property names shorter than tabWidth + 3 – for example, 5 characters in the default configuration, or 7 characters with tabWidth: 4. This heuristic may be revised in future versions.
// Prettier 2.2
const importantLink = {
url:
"https://prettier.io/docs/en/rationale.html#what-prettier-is-concerned-about",
gitHubUrl:
"https://github.com/prettier/prettier/blob/main/docs/rationale.md#what-prettier-is-concerned-about",
};
// Prettier 2.3
const importantLink = {
url: "https://prettier.io/docs/en/rationale.html#what-prettier-is-concerned-about",
gitHubUrl:
"https://github.com/prettier/prettier/blob/main/docs/rationale.md#what-prettier-is-concerned-about",
};
This started in 2017. Handlebars support has been in Prettier for a while, but it wasn’t released officially as it wasn’t really ready. Its status went from “alpha” to “experimental” to “beta” and then, if you checked older release notes, you can see that after “beta” somehow it was “alpha” again…
Well, anyway, it finally is happening: Prettier can now officially format HTML templates with Handlebars! 🎉
It uses Glimmer, Ember’s Handlebars parser, so it should be compliant with the HTML spec thanks to the Ember team.
The --html-whitespace-sensitivity option is supported and defaults to strict, which means that Prettier will always respect the presence or absence of whitespace around tags and consider it unsafe to add whitespace where there were none and vice versa as this can affect how the document is rendered in the browser. The css value is not yet supported (treated as strict for now).
The feature is called “Ember / Handlebars” and not just “Handlebars” because Glimmer doesn’t support some syntax and use cases of Handlebars. This is mostly due to the fact that Handlebars, being a template engine (a preprocessor), doesn’t care about the underlying syntax of the content it processes whereas Glimmer parses two syntaxes – HTML and Handlebars – at the same time and combines the result into a single tree, which Prettier can print. This means Prettier won’t format Handlebars files that can’t be parsed into such a tree, either because the underlying syntax isn’t HTML or because template directives and tags overlap in a way that can’t be represented in a tree (e.g., {{#if foo}}<div>{{/if}). Even with these restrictions, the formatter still seems to be useful enough to non-Ember Handlebars users. As for the syntax unsupported by Ember, there is a good chance to see support for it in future versions of Prettier as Glimmer uses a full-fledged Handlebars parser under the hood.
Files with the extensions .hbs and .handlebars are recognized as Handlebars by default. For other extensions, the --parser option with the value glimmer has to be specified – for example, using command line or, better yet, configuration overrides.
See the formatter in action on the playground!
// Prettier 2.2
const currying = (argument1) => (argument2) => (argument3) => (argument4) => (
argument5
) => (argument6) => foo;
// Prettier 2.3
const currying =
(argument1) =>
(argument2) =>
(argument3) =>
(argument4) =>
(argument5) =>
(argument6) =>
foo;
// Prettier 2.2
const { firstName, lastName } = useMemo(() => parseFullName(fullName), [
fullName,
]);
// Prettier 2.3
const { firstName, lastName } = useMemo(
() => parseFullName(fullName),
[fullName]
);
// Prettier 2.2
class loooooooooooooooooooong
extends looooooooooooooooooong
implements loooooooooooooooooooong {
property: string;
}
// Prettier 2.3
class loooooooooooooooooooong
extends looooooooooooooooooong
implements loooooooooooooooooooong
{
property: string;
}
While in general, Prettier avoids this kind of formatting because it's not diff-friendly, in this special case we decided that the benefits outweigh the risks.
If at least one element has a trailing single-line (// ...) comment on the same line, the concise formatting isn't applied. On the other hand, single-line comments placed on separate lines don't have such an effect and – as well as empty lines – can be used for logical grouping.
// Input
const lazyCatererNumbers = [1, 2, 4, 7, 11, 16, 22, 29, 37, 46,
// n > 10
56, 67, 79, 92, 106, 121, 137, 154, 172, 191, 211, 232, 254, 277, 301, 326, 352, 379, 407, 436, 466,
497, 529, 562, 596, 631, 667, 704, 742, 781,
// n > 40
821, 862, 904, 947, 991, 1036, 1082, 1129, 1177, 1226, 1276, 1327, 1379];
// Prettier 2.2
const lazyCatererNumbers = [
1,
2,
4,
7,
11,
16,
22,
29,
37,
// ... ✂ 46 lines ✂ ...
1379,
];
// Prettier 2.3
const lazyCatererNumbers = [
1, 2, 4, 7, 11, 16, 22, 29, 37, 46,
// n > 10
56, 67, 79, 92, 106, 121, 137, 154, 172, 191, 211, 232, 254, 277, 301, 326,
352, 379, 407, 436, 466, 497, 529, 562, 596, 631, 667, 704, 742, 781,
// n > 40
821, 862, 904, 947, 991, 1036, 1082, 1129, 1177, 1226, 1276, 1327, 1379,
];
Even though Prettier tries to be helpful here, please don't write code like this. Have mercy upon your teammates and use intermediate variables.
<!-- prettier-ignore -->// Input
const getAccountCount = async () =>
(await
(await (
await focusOnSection(BOOKMARKED_PROJECTS_SECTION_NAME)
).findItem("My bookmarks")).getChildren()
).length
// Prettier 2.2
const getAccountCount = async () =>
(
await (
await (await focusOnSection(BOOKMARKED_PROJECTS_SECTION_NAME)).findItem(
"My bookmarks"
)
).getChildren()
).length;
// Prettier 2.3
const getAccountCount = async () =>
(
await (
await (
await focusOnSection(BOOKMARKED_PROJECTS_SECTION_NAME)
).findItem("My bookmarks")
).getChildren()
).length;
do expressions in function calls (#10693 by @sosukesuzuki)“do expressions” are a stage 1 ECMAScript proposal.
// Prettier 2.2
expect(
do {
var bar = "foo";
bar;
}
).toBe("foo");
// Prettier 2.3
expect(do {
var bar = "foo";
bar;
}).toBe("foo");
// Prettier 2.2
const dotNotationMemberExpression = (callNode.parent?.type ===
AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent
).TSESTree.BinaryExpression;
const computedMemberExpression = (callNode.parent?.type ===
AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent)[TSESTree.BinaryExpression];
const callExpressionCallee = (callNode.parent?.type ===
AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent)(TSESTree.BinaryExpression);
const typeScriptAsExpression = (callNode.parent?.type ===
AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent) as TSESTree.BinaryExpression;
// Prettier 2.3
const dotNotationMemberExpression = (
callNode.parent?.type === AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent
).TSESTree.BinaryExpression;
const computedMemberExpression = (
callNode.parent?.type === AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent
)[TSESTree.BinaryExpression];
const callExpressionCallee = (
callNode.parent?.type === AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent
)(TSESTree.BinaryExpression);
const typeScriptAsExpression = (
callNode.parent?.type === AST_NODE_TYPES.ChainExpression
? callNode.parent.parent
: callNode.parent
) as TSESTree.BinaryExpression;
class attribute (#7865 by @thorn0)Formatting of HTML class names will now keep classes on one line until the line length limit is reached; at that point, consecutive classes with the same prefix will be grouped together on each line. For layout frameworks such as Bootstrap and Tailwind CSS, which add many classes to an element, this is important for readability and maintainability vs. the previous behavior (keeping all classes on one line) or e.g. putting each class on its own line.
<!-- prettier-ignore --><!-- Prettier 2.2 -->
<div
class="SomeComponent__heading-row d-flex flex-column flex-lg-row justify-content-start justify-content-lg-between align-items-start align-items-lg-center"
></div>
<!-- Prettier 2.3 -->
<div
class="
SomeComponent__heading-row
d-flex
flex-column flex-lg-row
justify-content-start justify-content-lg-between
align-items-start align-items-lg-center
"
></div>
// Input
a;
/*1*//*2*/
/*3*/
b;
// Prettier 2.2
a; /*2*/
/*1*/ /*3*/
b;
// Prettier 2.2 (second format)
a; /*2*/ /*3*/
/*1*/ b;
// Prettier 2.3
a;
/*1*/ /*2*/
/*3*/
b;
rangeStart (#9704 by @fisker)Previously, when range formatting was performed, such nodes were considered part of the range, now they're excluded. This affects other languages that the range formatting feature supports, not only JavaScript.
<!-- prettier-ignore -->// Input
foo = 1.0000;bar = 1.0000;baz=1.0000;
^^^^^^^^^^^^^ Range
// Prettier 2.2
foo = 1.0;
bar = 1.0;baz=1.0000;
// Prettier 2.3
foo = 1.0000;bar = 1.0;baz=1.0000;
// Input
<a><// comment
/a>;
// Prettier 2.2
<a></// comment
a>;
// Prettier 2.3
<a></
// comment
a
>;
An /* HTML */ comment should directly precede a template literal for the latter to be recognized as HTML-in-JS. Previously, the comment was erroneously recognized is some other locations.
// Input
foo /* HTML */ = `<DIV>
</DIV>`;
// Prettier 2.2 (--parser=babel)
foo /* HTML */ = `<div></div>`;
// Prettier 2.2 (--parser=meriyah)
foo /* HTML */ = `<DIV>
</DIV>`;
// Prettier 2.3 (All JavaScript parsers)
foo /* HTML */ = `<DIV>
</DIV>`;
// Input
// prettier-ignore
'use strict';
function foo() {
// prettier-ignore
"use strict";;
}
// Prettier 2.2
// prettier-ignore
'use strict';;
function foo() {
// prettier-ignore
"use strict";;
}
// Prettier 2.3
// prettier-ignore
'use strict';
function foo() {
// prettier-ignore
"use strict";
}
// Input
<p>
<span /> {this.props.data.title} <span />
//----- ^ U+3000 --------------- ^ U+3000
</p>
// Prettier 2.2
<p>
<span />
{this.props.data.title} <span />
//----- ^ U+3000 --------------- ^ U+3000
</p>;
// Prettier 2.2 (second format)
<p>
<span /> {this.props.data.title} <span />
//----- ^ U+3000 --------------- ^ U+3000
</p>;
// Prettier 2.3
<p>
<span /> {this.props.data.title} <span />
//----- ^ U+3000 --------------- ^ U+3000
</p>;
a(b => c => function (){}) (#10278 by @thorn0)Regression from v2.2.0.
<!-- prettier-ignore -->// Input
a(b => c => function (){})
// Prettier 2.2
TypeError: Cannot read property 'length' of undefined
// Prettier 2.3
a((b) => (c) => function () {});
// Input
class Foo {
@decorator([]) bar() {}
@decorator(
[]
) baz() {}
}
// Prettier 2.2
class Foo {
@decorator([]) bar() {}
@decorator([])
baz() {}
}
// Prettier 2.3
class Foo {
@decorator([]) bar() {}
@decorator([]) baz() {}
}
// Input
class C {
#field = 'value';
["method"]() {}
}
// Prettier 2.2 (with --no-semi)
class C {
#field = "value"
["method"]() {}
}
// Prettier 2.3 (with --no-semi)
class C {
#field = "value";
["method"]() {}
}
Support formatting for Module Blocks Stage 2 proposal.
<!-- prettier-ignore -->// Input
module { export let foo = "foo"; };
// Prettier 2.2
SyntaxError: Unexpected token, expected ";"
// Prettier 2.3
module {
export let foo = "foo";
};
yield in a pipeline (#10446 by @fisker)// Input
function* f() {
return x |> (yield #);
}
// Prettier 2.2
function* f() {
return x |> yield #;
}
// Prettier 2.3
function* f() {
return x |> (yield #);
}
Previously, because of the error recovery, the Babel parser was too permissive, which lead to all kinds of AST shapes that Prettier couldn’t print. Prettier 2.3 lets Babel recover only from a few harmless types of errors – for example, multiple const declarations with the same name. Anything else is reported as syntax errors.
// Input
foo("a", , "b");
// Prettier 2.2
TypeError: Cannot read property 'type' of null
// Prettier 2.3
[error] stdin: SyntaxError: Argument expression expected. (1:10)
[error] > 1 | foo("a", , "b");
[error] | ^
// Input
const \u{20} = 1
// Prettier 2.2
const = 1;
// Prettier 2.3
[error] stdin: SyntaxError: Invalid Unicode escape (1:7)
[error] > 1 | const \u{20} = 1
[error] | ^ ^
Another special case for number-only arrays.
<!-- prettier-ignore -->// Input
instantiate(game, [
transform([-0.7, 0.5, 0]),
render_colored_diffuse(game.MaterialDiffuse, game.Meshes["monkey_flat"], [1, 1, 0.3, 1]),
]);
// Prettier 2.2
instantiate(game, [
transform([-0.7, 0.5, 0]),
render_colored_diffuse(game.MaterialDiffuse, game.Meshes["monkey_flat"], [
1,
1,
0.3,
1,
]),
]);
// Prettier 2.3
instantiate(game, [
transform([-0.7, 0.5, 0]),
render_colored_diffuse(
game.MaterialDiffuse,
game.Meshes["monkey_flat"],
[1, 1, 0.3, 1]
),
]);
define (#10528 by @thorn0)Prettier special-cases AMD define calls to avoid unexpected line breaks in them. We now only format define calls if they are at the top level of a function or program and are passed arguments in the way AMD expects.
// Prettier 2.2
const someVariable = define("some string literal", anotherVariable, yetAnotherVariable);
// Prettier 2.3
const someVariable = define(
"some string literal",
anotherVariable,
yetAnotherVariable
);
prettier-ignore comments (#10666 by @fisker)// Input
foo = a.
// prettier-ignore
b;
// Prettier 2.2
foo =
// prettier-ignore
a.
// prettier-ignore
b;
// Prettier 2.3
foo = a.
// prettier-ignore
b;
mapDoc (#10695 by @thorn0)In particular, this fixes broken substitutions in HTML-in-JS.
<!-- prettier-ignore -->// Input
export default function include_photoswipe(
gallery_selector = ".my-gallery"
): string {
return /* HTML */ `
<script>
window.addEventListener("load", () =>
initPhotoSwipeFromDOM("${gallery_selector}")
);
</script>`;
}
// Prettier 2.2
export default function include_photoswipe(
gallery_selector = ".my-gallery"
): string {
return /* HTML */ ` <script>
window.addEventListener("load", () =>
initPhotoSwipeFromDOM("PRETTIER_HTML_PLACEHOLDER_0_13_IN_JS")
);
</script>`;
}
// Prettier 2.3
export default function include_photoswipe(
gallery_selector = ".my-gallery"
): string {
return /* HTML */ ` <script>
window.addEventListener("load", () =>
initPhotoSwipeFromDOM("${gallery_selector}")
);
</script>`;
}
// Input
glimseGlyphsHazardNoopsTieTie(({ a, b = () => {
console.log();
}}) => averredBathersBoxroomBuggyNurl());
// Prettier 2.2
glimseGlyphsHazardNoopsTieTie(({ a, b = () => {
console.log();
} }) => averredBathersBoxroomBuggyNurl());
// Prettier 2.3
glimseGlyphsHazardNoopsTieTie(
({
a,
b = () => {
console.log();
},
}) => averredBathersBoxroomBuggyNurl()
);
async in for-of (#10781 by @fisker)See https://github.com/tc39/ecma262/issues/2034
<!-- prettier-ignore -->// Input
for ((async) of []);
// Prettier 2.2
for (async of []);
// Prettier 2.2 (second format)
SyntaxError: Unexpected token, expected "=>" (1:15)
> 1 | for (async of []);
// Prettier 2.3
for ((async) of []);
async do expressions proposal (#10813 by @sosukesuzuki)See https://github.com/tc39/proposal-async-do-expressions
<!-- prettier-ignore -->// Input
const x = async do {
await requestAPI().json();
};
// Prettier 2.2
SyntaxError: Unexpected token, expected ";" (1:17)
// Prettier 2.3
const x = async do {
await requestAPI().json();
};
MethodDefinition (#9872 by @fisker)typescript parser only, babel-ts doesn't have this issue.
// Input
class Foo {
bar() /* bat */;
}
// Prettier 2.2
Error: Comment "bat" was not printed. Please report this error!
// Prettier 2.3
class Foo {
bar /* bat */();
}
// Input
type Foo = {
method(foo: "foo"): `
`
};
// Prettier 2.2
type Foo = {
method(
foo: "foo"
): `
`;
};
// Prettier 2.3
type Foo = {
method(foo: "foo"): `
`;
};
TypeScript has been supporting trailing commas in type parameters since TypeScript 2.7 released in January 2018. Prettier 2.3 prints them if the trailingComma option is set to all. Keep this option at the more conservative default value es5 if compatibility with TypeScript 2.7 or older is needed. Note that TypeScript still doesn't support trailing commas in type arguments (type parameter instantiations).
// Input
export class BaseSingleLevelProfileTargeting<
T extends ValidSingleLevelProfileNode,
> {
// ...
}
// Prettier 2.2
export class BaseSingleLevelProfileTargeting<
T extends ValidSingleLevelProfileNode
> {
// ...
}
// Prettier 2.3 with --trailling-comma=all
export class BaseSingleLevelProfileTargeting<
T extends ValidSingleLevelProfileNode,
> {
// ...
}
// Prettier 2.2
users.map(
(user: User): User => {
return user;
}
);
// Prettier 2.3
users.map((user: User): User => {
return user;
})
Necessary parentheses sometimes weren't printed in expressions containing non-null assertions. This has been fixed.
<!-- prettier-ignore -->// Input
const myFunction2 = (key: string): number =>
({
a: 42,
b: 42,
}[key]!)
// Prettier 2.2 (invalid syntax)
const myFunction2 = (key: string): number =>
{
a: 42,
b: 42,
}[key]!;
// Prettier 2.3
const myFunction2 = (key: string): number =>
({
a: 42,
b: 42,
}[key]!);
// Input
const accountCount = (findItemInSection(BOOKMARKED_PROJECTS_SECTION_NAME,
"My bookmarks") as TreeItem).getChildren().length;
// Prettier 2.2
const accountCount = (findItemInSection(
BOOKMARKED_PROJECTS_SECTION_NAME,
"My bookmarks"
) as TreeItem).getChildren().length;
// Prettier 2.3
const accountCount = (
findItemInSection(
BOOKMARKED_PROJECTS_SECTION_NAME,
"My bookmarks"
) as TreeItem
).getChildren().length;
// Input
type Uppercase<S extends string> = intrinsic;
// Prettier 2.2
Error: unknown type: "TSIntrinsicKeyword"
// Prettier 2.3
type Uppercase<S extends string> = intrinsic;
abstract Construct Signatures// Input
type T = abstract new () => void;
// Prettier 2.2
SyntaxError: Unexpected token, expected ";" (1:19)
// Prettier 2.3
type T = abstract new () => void;
// Input
import type A = require("A");
// Prettier 2.2
SyntaxError: Only ECMAScript imports may use 'import type'.
// Prettier 2.3
import type A = require("A");
// Input
type Foo = "1" | "2" /* two */ | "3";
// Prettier 2.2
type Foo = "1" | "2" | /* two */ "3";
// Prettier 2.3
type Foo = "1" | "2" /* two */ | "3";
// Input
foo as unknown as Bar
// Prettier 2.2
(foo as unknown) as Bar;
// Prettier 2.3
foo as unknown as Bar;
babel-ts (#10811 by @sosukesuzuki)override modifiers in class elementsclass Foo extends {
override method() {}
}
[key: KeyType]: ValueType) in classesclass Foo {
static [key: string]: Bar;
}
get / set in type declarationsinterface Foo {
set foo(value);
get foo(): string;
}
declare export * from … (#9767 by @fisker)// Input
declare export * from "ES6_ExportAllFrom_Source2";
// Prettier 2.2
declare export * from "ES6_ExportAllFrom_Source2"
// Prettier 2.3
declare export * from "ES6_ExportAllFrom_Source2";
this type annotation in functions via babel-flow (#10397 by @sosukesuzuki)this type annotation is supported since Babel 7.13.
// Input
var foo: (this: boolean) => void;
// Prettier 2.2
SyntaxError: Unexpected token, expected ")" (1:15)
// Prettier 2.3
var foo: (this: boolean) => void;
Prettier had trouble formatting some ranges in function declarations. SyntaxError was thrown. Prettier 2.3 formats these cases without errors. Examples of problematic ranges are shown below:
declare export function graphql<Props, Variables, Component: React$ComponentType<Props>>
// ^^^^^ range 1
(query: GQLDocument, config?: Config<Props, QueryConfigOptions<Variables>>):
(Component: Component) => React$ComponentType<$Diff<React$ElementConfig<Component>, {
data: Object|void,
// ^^^^ range 2
mutate: Function|void
}>>
// Input
const x: Obj['foo'] = 1;
// Prettier 2.2
// Error: unsupported node type "IndexedAccessType"
// Prettier 2.3
const x: Obj["foo"] = 1;
// Input
type T = Obj?.['foo'];
// Prettier 2.2
// Error: unsupported node type "OptionalIndexedAccessType"
// Prettier 2.3
type T = Obj?.['foo'];
--quote-props=preserve (#10323 by @thorn0)With the quoteProps option set to preserve and singleQuotes to false (default), double quotes are always used for printing strings, including situations like "bla\"bla". This effectively allows using --parser json5 for "JSON with comments and trailing commas".
// Input
{
"char": "\"",
}
// Prettier 2.2
{
"char": '"',
}
// Prettier 2.3
{
"char": "\"",
}
Prettier internally uses a JavaScript expression parser to parse JSON. That's why the json and json5 parsers used to be very forgiving and allowed all kinds of JavaScript expressions. Now they are much stricter, although some simple non-standard syntax is still allowed (e.g., JSON6 is supported, except for multiple minus signs: ----123).
// Input
[1, 2, 1 + 2]
// Prettier 2.2
[1, 2, 1 + 2]
// Prettier 2.3
SyntaxError: BinaryExpression is not allowed in JSON. (1:8)
> 1 | [1, 2, 1 + 2]
| ^
// Input
{key: "foo" + "bar"}
// Prettier 2.2 (--parser=json-stringify)
SyntaxError: BinaryExpression is not allowed in JSON. (1:7)
> 1 | {key: "foo" + "bar"}
| ^
// Prettier 2.3
SyntaxError: BinaryExpression is not allowed in JSON. (1:7)
> 1 | {key: "foo" + "bar"}
| ^^^^^^^^^^^^^
// Input
[{ a: 1.0000}, {"b": 2.0000 }]
// ^^^^^^^^^^^ range
// Prettier 2.2
SyntaxError: Unexpected token (1:4)
> 1 | "b": 2.0000
| ^
// Prettier 2.3
[{ a: 1.0000}, { "b": 2.0 }]
-custom-url() calls (#9966 by @vjeux)The CSS parser is parsing this as ["division", "absolute/path"] instead of a single "/absolute/path" token unless you are in a url() call. Because we put space after division, it results in an incorrect path. The fix was to avoid printing a space if a division is the first token of a call, which hopefully should be safe.
/* Input */
-custom-url(/absolute/path)
/* Prettier 2.2 */
-custom-url(/ absolute/path)
/* Prettier 2.3 */
-custom-url(/absolute/path)
@keyframes params from being parsed as a Less variable (#10773 by @tmazeika)/* Input */
@keyframes :global(spin) {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
/* Prettier 2.2 */
@keyframes: global(spin){
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
};
/* Prettier 2.3 */
@keyframes :global(spin) {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
// Input
.simplification {
foo: (
calc() // not a comment anymore
);
}
// Prettier 2.2
.simplification {
foo: (calc() // not a comment anymore);
}
// Prettier 2.3
.simplification {
foo: (
calc() // not a comment anymore
);
}
// Input
$map: (
('my list'): 'hello world',
);
// Prettier 2.2
TypeError: Cannot read property 'length' of undefined
// Prettier 2.3
$map: (
("my list"): "hello world",
);
{{!-- Input --}}
{{~! Comment }}
{{! Comment ~}}
{{~! Comment ~}}
{{!-- Prettier 2.2 --}}
{{! Comment }}
{{! Comment }}
{{! Comment }}
{{!-- Prettier 2.3 --}}
{{~! Comment }}
{{! Comment ~}}
{{~! Comment ~}}
--html-whitespace-sensitivity strict
{{!-- Input --}}
<span>123 {{mustache}}</span>
<span>
123 {{mustache}}</span>
<span>123 {{mustache}}
</span>
<span>
123 {{mustache}}
</span>
{{!-- Prettier 2.2 --}}
<span>
123 {{mustache}}
</span>
<span>
123 {{mustache}}
</span>
<span>
123 {{mustache}}
</span>
<span>
123 {{mustache}}
</span>
{{!-- Prettier 2.3 --}}
<span>123 {{mustache}}</span>
<span>
123
{{mustache}}</span>
<span>123
{{mustache}}
</span>
<span>
123
{{mustache}}
</span>
blockParam on its own line (#9978 by @dcyriller){{!-- Input --}}
<MyComponent @prop={{true}} @prop2={{true}} @prop3={{true}} @prop4={{true}} as |thing|></MyComponent>
{{#block param hashKey=hashValue hashKey=hashValue hashKey=hashValue as |blockParam|}}
Hello
{{/block}}
{{!-- Prettier 2.2 --}}
<MyComponent
@prop={{true}}
@prop2={{true}}
@prop3={{true}}
@prop4={{true}} as |thing|
/>
{{#block
param
hashKey=hashValue
hashKey=hashValue
hashKey=hashValue as |blockParam|
}}
Hello
{{/block}}
{{!-- Prettier 2.3 --}}
<MyComponent
@prop={{true}}
@prop2={{true}}
@prop3={{true}}
@prop4={{true}}
as |thing|
/>
{{#block
param
hashKey=hashValue
hashKey=hashValue
hashKey=hashValue
as |blockParam|
}}
Hello
{{/block}}
{{ in attributes and text' and " for attributes with interpolations[object Object] printed in the class attributeclass attribute, like Prettier formatted it in HTML before v2.3.0{{!-- Input --}}
<div class="
foo"></div>
<div bar='"{{expr}}"'></div>
<div baz="\{{ non-expression }}"></div>
{{!-- Prettier 2.2 --}}
<div class="[object Object],foo"></div>
<div bar=""{{expr}}""></div>
<div baz="{{ non-expression }}"></div>
{{!-- Prettier 2.3 --}}
<div class="foo"></div>
<div bar='"{{expr}}"'></div>
<div baz="\{{ non-expression }}"></div>
{{!-- Input --}}
<div>
A long enough string to trigger a line break that would prevent wrapping more and more.
</div>
{{!-- Prettier 2.2 --}}
<div>
A long enough string to trigger a line break that would prevent wrapping more and more.
</div>
{{!-- Prettier 2.3 --}}
<div>
A long enough string to trigger a line break that would prevent wrapping more
and more.
</div>
{{! Input }}
<span class="stampFont" style="font-family: 'stampfont'"></span>
{{! Prettier 2.2 }}
<span class="stampFont" style="font-family: 'stampfont'"></span>
{{! Prettier 2.3 }}
<span class="stampFont" style="font-family: 'stampfont'"></span>
{{!-- Input --}}
<GlimmerComponent
@errors={{or this.aVeryLongProperty (and this.aProperty (v-get bike "number" "message"))}}
data-test-beneficiary-account-number
/>
<GlimmerComponent
@progress={{aPropertyEngdingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}}
/>
{{!-- Prettier 2.2 --}}
<GlimmerComponent
@errors={{
or
this.aVeryLongProperty
(and this.aProperty (v-get bike "number" "message"))
}}
data-test-beneficiary-account-number
/>
<GlimmerComponent
@progress={{
aPropertyEngdingAfterEightiethColumnToHighlightAWeirdClosingParenIssue
}}
/>
{{!-- Prettier 2.3 --}}
<GlimmerComponent
@errors={{or
this.aLongProperty
(and this.aProperty (v-get bike "number" "message"))
}}
data-test-beneficiary-account-number
/>
<GlimmerComponent
@progress={{aPropertyEngdingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}}
/>
# Input
query ($unnamed: String) {
id
}
# Prettier 2.2
query($unnamed: String) {
id
}
# Prettier 2.3
query ($unnamed: String) {
id
}
<!-- Input -->
Markdown
```js
"· "
```
<!-- Prettier 2.2 -->
Markdown
```js
"· ";
```
<!-- Prettier 2.3 -->
Markdown
```js
"· ";
```
<!-- Input -->
---
---
# Title
a|b|c|
|:--|:-:|--:|
|d|e|f|
---
text
<!-- Prettier 2.2 -->
---
---
# Title
a|b|c|
|:--|:-:|--:|
|d|e|f|
---
text
<!-- Prettier 2.3 -->
---
---
# Title
| a | b | c |
| :-- | :-: | --: |
| d | e | f |
---
text
Add the ability to delimit the end of front matter with ....
<!-- Input -->
---
title: Hello
slug: home
...
Markdown
<!-- Prettier 2.2 -->
---
title: Hello
slug: home
...
Markdown
<!-- Prettier 2.3 -->
---
title: Hello
slug: home
...
Markdown
Prettier couldn't parse this valid YAML. Thanks to Eemeli Aro for fixing this bug in the underlying parser.
<!-- prettier-ignore --># Input
key1: &default
subkey1: value1
key2:
<<: *default
# Prettier 2.2
SyntaxError: Nested mappings are not allowed in compact mappings (1:7)
# Prettier 2.3
key1: &default
subkey1: value1
key2:
<<: *default
.prettierrc as YAML when formatting it (#8105 by @fisker)The .prettierrc file can be written in either JSON or YAML. Previously, when Prettier formatted it, the parser was inferred to be json, which lead to a SyntaxError thrown if the content was YAML. Now it’s treated as a YAML file. However, if it's JSON, it will be formatted as JSON (not as JSON-like YAML).
concat (#9733 by @fisker, @thorn0)To simplify the code of AST printers, the data structure for the concatenation command has been changed from { type: 'concat', parts: Doc[] } to Doc[]. The old format is deprecated, but for compatibility, the doc printer still supports it, and doc.builders.concat (as well as some other builder functions) will keep using it until the next major version of Prettier.
If you're a plugin author, this change should only concern you if your plugin introspects or modifies composed docs. If it happens to be the case, please make your plugin compatible with future versions of Prettier by tweaking the introspecting code to support the new format. There also is an off-chance where this change can break things, namely if a plugin calls another plugin to print an embedded language and then introspects the returned doc. There seems to be no reason for plugins to do that though.
To replace concat(…) calls in your plugins, you can try auto-fix by this ESLint rule prettier-doc/no-concat.
// Prettier 2.2
myDoc = group(concat(["foo", line, "bar"]));
// Prettier 2.3
myDoc = group(["foo", line, "bar"]);
lineSuffixBoundary IR command (#10122 by @thorn0)There was a bug in the implementation of the lineSuffixBoundary command that significantly limited its usefulness: the printer algorithm didn't correctly consider it a potential line break. Now that the bug has been fixed, we urge plugin authors to give this command another try and see if it can help them simplify printing of trailing comments.
// Input
group([
"let foo = [",
indent([
softline,
[lineSuffixBoundary, "item1,"],
line,
[lineSuffixBoundary, "item2,", lineSuffix(" // comment")],
line,
[lineSuffixBoundary, "item3"],
]),
softline,
"];",
])
// Prettier 2.2
let foo = [item1, item2, // comment
item3];
// Prettier 2.3
let foo = [
item1,
item2, // comment
item3
];
indentIfBreak IR command (#10221 by @thorn)indentIfBreak(doc, { groupId }) is an optimized version of ifBreak(indent(doc), doc, { groupId }).
print callback (#10557 by @fisker)The third argument of the print method of plugin printers (the print callback) has been updated. Its first argument can be a string or an array of strings now.
To print the current node, call print without arguments:
function print(path, options, print) {
const parts = [];
path.each((childPath) => {
- parts.push(print(childPath));
+ parts.push(print());
}, "children");
return parts;
}
To print a property of the current node, use "property" or ["property"]:
function print(path, options, print) {
- return path.call(print, "property");
+ return print("property");
}
To print a sub-property of the current node, use ["property1", "property2"]:
function print(path, options, print) {
// print `node.child.child`
- return path.call(print, "child", "child");
+ return print(["child", "child"]);
}
See also an example in the docs.
The Prettier CLI will no longer display an error when no files match the glob pattern passed as input.
# Prettier 2.2
$ npx prettier --check "prettier/docs/*.yaml"
Checking formatting...
[error] No files matching the pattern were found: "prettier/docs/*.yaml".
All matched files use Prettier code style!
# Prettier 2.3
$ npx prettier --check --no-error-on-unmatched-pattern "prettier/docs/*.yaml"
Checking formatting...
All matched files use Prettier code style!
A new --debug-print-comments CLI flag and corresponding functionality for the Playground.
--debug-print-doc (#10169, #10177 by @thorn0)The idea is to make the output of --debug-print-doc closer to actual code for generating docs (Prettier's intermediate representation). Ideally, it should be possible for it to work without modification after copy-pasting into a JS file. That ideal hasn't probably been reached by this PR, but it's pretty close. This is going to make --debug-print-doc and the corresponding part of the Playground a bit more useful.
--find-config-path can't find config file (#10208 by @fisker)# Prettier 2.2
$ prettier --find-config-path /prettier.js
# Silently failed
# Prettier 2.3
$ prettier --find-config-path /prettier.js
[error] Can not find configure file for "/prettier.js"
# Prettier 2.2
$ prettier tests/flow-repo/config_module_system_node_resolve_dirname --check
Checking formatting...
tests\flow-repo\config_module_system_node_resolve_dirname\custom_resolve_dir\tes
tests\flow-repo\config_module_system_node_resolve_dirname\custom_resolve_dir\tes
tests\flow-repo\config_module_system_node_resolve_dirname\subdir\custom_resolve_
All matched files use Prettier code style!
# Prettier 2.3
$ prettier tests/flow-repo/config_module_system_node_resolve_dirname --check
Checking formatting...
All matched files use Prettier code style!
constructor (#10256 by @ashlkv)Directories whose names happened to coincide with the properties of Object.prototype were ignored by Prettier CLI because of a classic bug (introduced in Prettier 2.0.0) with object properties not being checked for being own.
# Prettier 2.2
$ prettier "js/constructor/*.js" --write
[error] No matching files. Patterns: js/constructor/*.js
# Prettier 2.3
$ prettier "js/constructor/*.js" --write
js/constructor/test.js 42ms