greenkeeper[bot]
commented
7 years ago Version 1.3.1 just got published.
Your tests are still failing with this version. Compare the changes 🚨
Open greenkeeper[bot] opened 7 years ago
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
This is the most requested feature for prettier. With 1.4.0, you can now use prettier to format your .ts and .tsx files!
The way prettier works is by using those project to generate an AST representation of the code and print it. Both babylon (the parser that powers babel) and flow are producing an AST approximately following the estree format for the JavaScript parts and then have special nodes for Flow-specific ones.
TypeScript, the same way as Flow, introduces special nodes for the syntax it introduces. Unfortunately, it doesn't follow the estree format for the rest of the JavaScript language. This puts us in a rough spot with prettier as we would have to essentially completely fork it in order to print TypeScript.
This incompatibility with the AST is not a new problem and another project struggled with it: ESLint. Because the AST is different, none of the ESLint rules are working. Fortunately for us, @JamesHenry and @soda0289 wrote a project called typescript-eslint-parser which takes a TypeScript AST and convert it to an estree one, just what we need for prettier!
After that project got setup inside of prettier, @azz, @despairblue and @Pajn implemented all the TypeScript-specific nodes and ensured that the 13k tests of the TypeScript test suite are correctly passing. This was a huge undertaking and it is finally ready to be used :)
We tested prettier on the biggest TypeScript projects we could find on GitHub to ensure that it prints correct code. We haven't spent a lot of time trying to optimize the way code is formatted yet, so if you see something strange, please raise an issue!
While TypeScript is the most requested feature from open source, CSS is the biggest one from Facebook engineers. Once you are used to pretty print your code in one language, you want to do it everywhere!
It turns out that CSS is a much smaller language than JavaScript and supporting it only took a few days. We are using postcss by @ai as the underlying parser which is able to parse CSS, Less and SCSS. We also depend on postcss-values-parser, postcss-selector-parser by @ben-eb postcss-media-query-parser by @dryoma.
Unfortunately, postcss right now doesn't parse Sass nor Stylus. We'd be happy to support them if someone is willing to do the work of printing them.
Note that prettier is currently just formatting the code, it does not respect any options yet such as singleQuote nor is doing any color or number normalization like we do for JavaScript.
The first phase of the project was to make prettier output correct and good looking code. Now that it's in a good shape, we can spend time on making the integrations better. We just introduced support for two great features: maintain cursor position and being able to format a range instead of the entire file.
Note that we just landed the support inside of prettier itself, none of the editor integrations are using it yet. Also, we haven't really tried them out in practice so we're likely going to have to fix rough edges with them!
cursorOffset option for cursor translation (#1637) by @josephfrazierRight now, we let editors figure out where the cursor should be, which they do an okay job at. But since we are printing the code, we can give the correct position!
--range-start/end options to format only parts of the input (#1609) by @josephfrazierThis one is a very often requested feature. Right now prettier only formats the entire file. Now it is possible to format a range.
The way it works is by going up through the AST in order to find the closest statement. This way you don't need to select exactly the right range that is valid. You can just drag in the rough place where the code you want to reformat it, and it's going to!
Since we are now formatting CSS and TypeScript, it is not convenient to have to specify the parser for every file. You can now pass the filepath of the file you are working on and prettier will read the extension and figure out the right parser to use.
The biggest remaining issue that people have with prettier when printing JSX is when it is used when printing text. The behavior of prettier used to add an ugly {" "} before and if a line was too long, just leave it alone. Now we treat each word as a token and are able to make it flow correctly.
This is an awesome piece of work by @karl as not only did he implement the feature, but also introduced a new primitive inside of prettier in order to print a sequence of elements and break as soon as one hits the edge.
// Before
<div>
Please state your
{" "}
<b>name</b>
{" "}
and
{" "}
<b>occupation</b>
{" "}
for the board of directors.
</div>
// After
<div>
Please state your <b>name</b> and <b>occupation</b> for the board of
directors.
</div>People writing functional components are going to be happy about this one. We no longer put parens for arrow functions that return JSX.
// Before
const render1 = ({ styles }) => (
<div style={styles}>
Keep the wrapping parens. Put each key on its own line.
</div>
);
// After
const render1 = ({ styles }) =>
<div style={styles}>
Keep the wrapping parens. Put each key on its own line.
</div>;Template literal printing has always caused prettier a lot of difficulties. With 1.3.0 we massively improved the situation and with this release, I believe that we handle all the common situations in a good way.
In order to workaround issues, we added an utility that removes empty lines from the output, but it yielded some really weird results sometimes, this is now gone. Another tweak we've done is instead of indenting when ${ starts, we indent where the line that contains ${ starts.
Let us know if you still have issues with how template literals output after this release!
// Before
const Bar = styled.div`
color: ${props => (props.highlight.length > 0 ? palette([
'text',
'dark',
'tertiary'
])(props) : palette([
'text',
'dark',
'primary'
])(props))} !important;
`
// After
const Bar = styled.div`
color: ${props =>
props.highlight.length > 0
? palette(["text", "dark", "tertiary"])(props)
: palette(["text", "dark", "primary"])(props)} !important;
`We have a lot of fine-tuned logic for how to break things after assignment (eg a = ...). We are now using the same one for object values. This should help for multi-line boolean logic, or big conditionals. This is also a good example of how we can create a consistent printer.
// Before
const o = {
somethingThatsAReallyLongPropName: this.props.cardType ===
AwesomizerCardEnum.SEEFIRST,
};
// After
const o = {
somethingThatsAReallyLongPropName:
this.props.cardType === AwesomizerCardEnum.SEEFIRST,
};There's been a steady stream of people complaining about the way it was rendered and was put on the list of things that are probably hard to do, will check later. It turned out to be super easy, so here you go!
// Before
const anyTestFailures = !(aggregatedResults.numFailedTests === 0 &&
aggregatedResults.numRuntimeErrorTestSuites === 0);
// After
const anyTestFailures = !(
aggregatedResults.numFailedTests === 0 &&
aggregatedResults.numRuntimeErrorTestSuites === 0
);We were already doing this for if statements, we should be consistent and also do it for loops.
// Before
for (a in b)
var c = {};
// After
for (a in b) var c = {};We shouldn't indent things twice ;)
// Before
type Foo = Promise<
| { ok: true, bar: string, baz: SomeOtherLongType }
| { ok: false, bar: SomeOtherLongType }
>;
// After
type Foo = Promise<
{ ok: true, bar: string, baz: SomeOtherLongType } |
{ ok: false, bar: SomeOtherLongType }
>;The detection code for whether an arrow function should be written without parenthesis just checked if there was a comment, but instead we only want comments that are inline like (/* comment */ num), not end of line comments.
// Before
KEYPAD_NUMBERS.map((num) => ( // Buttons 0-9
<div />
));
KEYPAD_NUMBERS.map(num => ( // Buttons 0-9
<div />
));This avoids making it seems like it is indented by 4 characters instead of two. The downside is that if the condition is multi-line it's not going to be properly aligned, but I feel it's a better trade-offs. If you are doing nested ternaries, you usually have small conditions.
// Before
aaaaaaaaaaaaaaa
? bbbbbbbbbbbbbbbbbb
: ccccccccccccccc
? ddddddddddddddd
: eeeeeeeeeeeeeee ? fffffffffffffff : gggggggggggggggg;
// After
aaaaaaaaaaaaaaa
? bbbbbbbbbbbbbbbbbb
: ccccccccccccccc
? ddddddddddddddd
: eeeeeeeeeeeeeee ? fffffffffffffff : gggggggggggggggg;We don't need to use the indentation to disambiguate another block as nothing can come after.
// Before
<div
src={
!isEnabled &&
diffUpdateMessageInput != null &&
this.state.isUpdateMessageEmpty
}
/>;
// After
<div
src={
!isEnabled &&
diffUpdateMessageInput != null &&
this.state.isUpdateMessageEmpty
}
/>;We are already trying to cleanup strings in various ways, this is another small addition that's going to remove \ that are not needed.
// Before
a = 'hol\a';
// After
a = 'hola';We want to inline objects inside of a boolean expression as it looks weird to have { on its own line. But it turns out that it leads to weird behaviors for empty objects. So we keep them on their own line if they are empty.
const x = firstItemWithAVeryLongNameThatKeepsGoing ||
secondItemWithALongNameAsWell || {};
// After
const x =
firstItemWithAVeryLongNameThatKeepsGoing ||
secondItemWithALongNameAsWell ||
{};It is common to assign multiple values inside of a for loop, now we don't add parenthesis anymore.
// Before
for ((i = 0), (len = arr.length); i < len; i++) {
// After
for (i = 0, len = arr.length; i < len; i++) {If you put block comments inside of arrow functions, we no longer mess everything up!
// Before
export const bem = block => /**
* @param {String} [element] - the BEM Element within that block; if undefined, selects the block itself.
*/
element => /**
* @param {?String} [modifier] - the BEM Modifier for the Block or Element; if undefined, selects the Block or Element unmodified.
*/
modifier =>
// After
export const bem = block =>
/**
* @param {String} [element] - the BEM Element within that block; if undefined, selects the block itself.
*/
element =>
/**
* @param {?String} [modifier] - the BEM Modifier for the Block or Element; if undefined, selects the Block or Element unmodified.
*/
modifier =>Another place where we have to do special logic for comments!
// Before
import {
ExecutionResult,
DocumentNode,
/* tslint:disable */
SelectionSetNode,
} /* tslint:enable */ from 'graphql';
// After
import {
DocumentNode,
/* tslint:disable */
SelectionSetNode,
/* tslint:enable */
} from 'graphql';We handled some placements before and kept adding places where they could appear, now we switch to a more general approach. Hopefully those issues shouldn't crop up in the future anymore.
// Before
const configModel = this.baseConfigurationService.getCache().consolidated // global/default values (do NOT modify)
.merge(this.cachedWorkspaceConfig);
// After
const configModel = this.baseConfigurationService
.getCache()
.consolidated // global/default values (do NOT modify)
.merge(this.cachedWorkspaceConfig);// Before
f(action => next =>
next(action));
// After
f(action => next =>
next(action),
);This mostly affects Facebook engineers where we automatically add $FlowFixMe when pushing a new version of flow. Now it no longer messes up those comments.
// Before
const aDiv = /* $FlowFixMe */
(
<div className="foo">
Foo bar
</div>
);
// After
const aDiv = (
/* $FlowFixMe */
<div className="foo">
Foo bar
</div>
);This one has been very often requested. We used to only break multiple variable declarations if the line was > 80 columns. Now we do it regardless if there's at least one with an assignment.
// Before
var numberValue1 = 1, numberValue2 = 2;
// After
var numberValue1 = 1,
numberValue2 = 2;The expanded version of flow union looks good when they are many objects but if it's used for nullability, the it looks very weird. We're now inlining | null and | void.
// Before
interface RelayProps {
articles:
| Array<
| {
__id: string,
}
| null
>
| null
}
// After
interface RelayProps {
articles: Array<{
__id: string,
} | null> | null,
}We no longer break on extends. This should make classes with extends that can break look less wonky.
// Before
class MyContractSelectionWidget
extends React.Component<
void,
MyContractSelectionWidgetPropsType,
void
> {
method() {}
}
// After
class MyContractSelectionWidget extends React.Component<
void,
MyContractSelectionWidgetPropsType,
void
> {
method() {}
}The same way we don't break long require calls, we no longer break import statements if there is only a single thing being imported.
// Before
import somethingSuperLongsomethingSuperLong
from "somethingSuperLongsomethingSuperLongsomethingSuperLong";
// After
import somethingSuperLongsomethingSuperLong from "somethingSuperLongsomethingSuperLongsomethingSuperLong";Did you know that if none of your code were statements, you could use () instead of {} and , instead of ;? Now you do. Some people exploit this fact when returning things from arrow functions. This is not recommended but it's easy to support in prettier so might as well ¯_(ツ)_/¯
// Before
const f = (argument1, argument2, argument3) =>
(doSomethingWithArgument(argument1), doSomethingWithArgument(
argument2
), argument1);
// After
const f = (argument1, argument2, argument3) => (
doSomethingWithArgument(argument1),
doSomethingWithArgument(argument2),
argument1
);Loops with empty body no longer have their {} split into two lines.
// Before
while (true) {
}
// After
while (true) {}// Before
switch (true) {
case true:
// Good luck getting here
case false:
}
// After
switch (true) {
case true:
// Good luck getting here
case false:
}We used to find where to put comments by traversing the AST using the definition from ast-types. This occasionally caused issues when some field wasn't declared, we wouldn't find the node and either print comments in an incorrect location or throw an error. It turns out that we don't need to keep this mapping and can just traverse the objects and if a node has a type field, then it's a node.
// Before
Error: did not recognize object of type "ObjectTypeSpreadProperty"
// After
type X = {...Y/**/};
type X = {/**/...Y};If you were adding invisible characters inside of JSX text, we would replace them by regular spaces. I don't know why anyone would ever want to do that, but now we print it back as is!
We used to have some pretty complicated (and not working well) code to handle comments inside of template literals. We introduced a really nice solution for JSX {} expressions. The idea is to introduce a boundary before the end of the } and if we still have unprinted comments, then flush them all at once, put a \n and print the }. We are now using this logic for template literals :)
// Before
`${0} // comment`;
// After
`${
0
// comment
}`;We don't have an automated way to put parenthesis, we instead specify all the possible combinations of nodes and when they should or shouldn't have parenthesis. So there's likely a long tail of unusual combinations that are still remaining. In this case, we made await handling a lot more robust by both adding parenthesis where they are needed and removing them when they are not.
// Before
(await spellcheck) && spellcheck.setChecking(false);
new A((await x));
// After
await (spellcheck && spellcheck.setChecking(false));
new A(await x);Another long tail option that we haven't got right!
// Before
type T = { method: () => void };
// After
type T = { get method(): void }Another case of sneaky parenthesis that we didn't properly add!
// Before
type ExtractType = <A>B<C> => D
// After
type ExtractType = <A>(B<C>) => DWe want prettier to be able to parse all the JavaScript out there. For babylon parser, we have to chose whether a file is using strict mode or not. We opted in to use strict mode by default as most files parse that way. But if you have octal literals like 0775, it would not even parse. Now if it fails to parse in strict mode, we're going to try again in non-strict. We also allow return outside of a function as it's valid in node files.
// Before
SyntaxError
// After
return 0775;--write to be used with --list-different (#1633)This is useful to combine the two if you are writing a commit hook to tell the user what actually changed in a single command.
It's very easy to run prettier over the node_modules/ folder by mistake which is something you almost never want to. So now we disable it by default and add a --with-node-modules option if you really want to.
We enabled the option to go through .dotfiles in the glob parsing library we are using. This means that writing * will now catch .eslintrc.
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
This is the release I've been waiting for a very long time: one that has only minimal changes to JavaScript!
For the past 6 months, we kept doing changes to various aspects of printing JavaScript, with the hope that one day we would get to a stable place. No automated tool is going to print perfect code for all the possible edge cases. The goal is to find a good place where when people report code that is printed in a funny way, we can't make it better without making other pieces of code look worse, introduce behavior that's very hard to understand for humans and doesn't introduce some disproportionate complexity to the codebase.
We're not 100% there yet, but we're closer than ever!
Now that JavaScript needs for support is trending down, it's an opportunity to support other languages that front-end developers are working on and want formatted. We've introduced TypeScript and CSS in the last release and are doing a batch of fixes for them in this release. We're also adding support for new languages: GraphQL queries, embedding CSS-in-JS and JSON are now available in prettier!
Prettier is not only a useful tool but it's also a really cool piece of technology. @karl spent a bunch of time improving JSX support and in the process implemented a new primitive to prettier: fill. He wrote a very interesting blog post Adding a new layout strategy to Prettier that I highly recommend reading if you're interested in how prettier is working behind the scenes.
Thanks to @stubailo, @jnwng, @tgriesser and @azz, prettier now supports printing GraphQL queries!
It works for .graphql files and within JavaScipt templates that start with graphql, graphql.experimental and gql in order to work with Relay and Apollo.
ReactDOM.render(
<QueryRenderer
query={graphql`
query appQuery {
viewer {
...TodoApp_viewer
}
}
`}
// ...
/>,
mountNode
);Note that it only supports the open source syntax of GraphQL, therefore doesn't work with Relay Classic, it only works with Relay Modern.
If you are using styled-components or styled-jsx, prettier will now reformat the CSS inside of your template expressions.
const EqualDivider = styled.div`
margin: 0.5rem;
padding: 1rem;
background: papayawhip;
> * {
flex: 1;
&:not(:first-child) {
${props => (props.vertical ? "margin-top" : "margin-left")}: 1rem;
}
}
`;This was pretty straightforward to implement but nonetheless very useful. Thanks to @josephfrazier for doing it :)
{
"name": "prettier",
"version": "1.5.0",
"description": "Prettier is an opinionated JavaScript formatter",
"bin": {
"prettier": "./bin/prettier.js"
}
}I'm really excited because we only put a few days to build the initial CSS support and it has worked surprisingly well. This release brings a handful of important improvements to CSS but nothing that required big changes.
The biggest unknown when printing CSS was how to deal with multiple selectors. The initial approach we took was to use the 80 columns rule where we would only split if it was bigger than that. Many people reported that they were using another strategy for this: always break after a ,. It turns out that many popular codebases are using this approach and it feels good as you can see the structure of the selectors when layed out on-top of each others.
// Before
.clusterPlannerDialog input[type="text"], .clusterPlannerDialog .uiTypeahead {
// After
.clusterPlannerDialog input[type="text"],
.clusterPlannerDialog .uiTypeahead {The concept of code formatting has blurry boundaries. The core aspect of it is around whitespaces but some things like single vs double quotes and semi-colons are usually bundled with it. With prettier on JavaScript, we also lightly reformat strings by removing extra \ and normalize numbers. For CSS, we need to do a similar interpretation of where the boundary ends. For colors, we decided to turn all the letters into lowercase and stop there. Turning rgb() into hex or 6 hex into 3 hex is out of scope.
// Before
.foo {
color: #AAA;
-o-color: #fabcd3;
-ms-color: #AABBCC;
}
// After
.foo {
color: #aa;
-o-color: #fabcd3;
-ms-color: #aabbcc;
}The new fill primitive turned out to be very useful for CSS. For long values, instead of breaking and putting a \n before every element, we can instead only put a \n when it goes over the limit. It leads to much better looking code.
// Before
border-left:
1px
solid
mix($warningBackgroundColors, $warningBorderColors, 50%);
// After
border-left: 1px solid
mix($warningBackgroundColors, $warningBorderColors, 50%);This is another small fix in the journey of properly supporting a new language. We now encode the ability to break on long @media rules.
// Before
@media all and (-webkit-min-device-pixel-ratio: 1.5), all and (-o-min-device-pixel-ratio: 3/2), all and (min--moz-device-pixel-ratio: 1.5), all and (min-device-pixel-ratio: 1.5) {
}
// After
@media all and (-webkit-min-device-pixel-ratio: 1.5),
all and (-o-min-device-pixel-ratio: 3/2),
all and (min--moz-device-pixel-ratio: 1.5),
all and (min-device-pixel-ratio: 1.5) {
}Less and Scss are turning into real programming languages :) Step by step, we're starting to print all their constructs in the same way as JavaScript. This time, it's the else placement.
// Before
@if $media == phonePortrait {
$k: .15625;
}
@else if $media == tabletPortrait {
$k: .065106;
}
// After
@if $media == phonePortrait {
$k: .15625;
} @else if $media == tabletPortrait {
$k: .065106;
}While we want prettier to format the entire codebase, there are times where we "know better" and want an escape hatch. This is where the prettier-ignore comment comes in. It wasn't working for CSS but that was an oversight, now it is implemented :)
// Before
foo {
/* prettier-ignore */
thing: foo;
-ms-thing: foo;
}
// After
foo {
/* prettier-ignore */
thing: foo;
-ms-thing: foo;
}In order to be fast, many "packagers" do not parse files in order to extract dependencies but instead use a crude regex. This is a reason why we don't break long require() calls and it happens to also affect CSS Modules. If you add new lines in the composes field, it doesn't recognize it anymore. So we're no longer breaking it there, even if it goes over 80 columns.
// Before
.reference {
composes:
selector
from
"a/long/file/path/exceeding/the/maximum/length/forcing/a/line-wrap/file.css";
}
// After
.reference {
composes: selector from "a/long/file/path/exceeding/the/maximum/length/forcing/a/line-wrap/file.css";
}We made a decision to have only a single high level "parser" for CSS, SCSS and Less even though we are using postcss-less and postcss-scss under the hood. We use a regex to figure out which parser to try first and fallback to the other one if a syntax error is thrown. Unfortunately, for certain features, the first (incorrect) parser doesn't throw and instead skips some elements. So, we need to beef up the regex to make sure we are right for the early detection.
Thankfully, this hack is working well in practice. If we find a lot more edge cases, we'll likely want to do the right thing(tm) and split them into two parsers.
// Before
@import "text-shadow";
// After
@import "rounded-corners", "text-shadow";TypeScript support is now solid, all the changes for this release are small edge cases.
The core algorithm of prettier is to expand a group if all the elements do not fit. It works really well in practice for most of JavaScript but there's one case it doesn't handle very well is when there are two groups side by side, in this case: <Generics>(Arguments). We have to carefully create groups such that arguments expand first as this is generally what people expect.
// Before
export const forwardS = R.curry(<
V,
T
>(prop: string, reducer: ReducerFunction<V, T>, value: V, state: {[name: string]: T}) =>
R.assoc(prop, reducer(value, state[prop]), state)
);
// After
export const forwardS = R.curry(
<V, T>(
prop: string,
reducer: ReducerFunction<V, T>,
value: V,
state: { [name: string]: T }
) => R.assoc(prop, reducer(value, state[prop]), state)
);For better or worse, we decided to manually handle adding parenthesis. So when a new operator is introduced, we need to make sure that we add correct parenthesis when nested with any other combination of operators. In this case, we missed await inside of TypeScript !.
// Before
const bar = await foo(false)!;
// After
const bar = (await foo(false))!;We use typescript-eslint-parser project that translates TypeScript AST into estree AST in order for prettier to print it. From time to time we're going to find edge cases that it doesn't handle yet. In this case, it didn't give a way to tell that there's an empty {}, which apparently is important for TypeScript. Thankfully, the team is very responsive and they fixed it after we put a workaround inside of prettier.
// Before
import from "@types/googlemaps";
// After
import {} from "@types/googlemaps";The code that implements interface is shared with the code that prints objects, which contains a rule to keep them expanded if there's a \n inside. But, this is not the intended behavior for interfaces. We always want to expand, like we do for classes, even if it fits 80 columns.
// Before
interface FooBar { [id: string]: number; }
// After
interface FooBar {
[id: string]: number;
}no-semi and semi are often requested but on the prettier team we're one step ahead and implemented two-semi for you! Just kidding, it was a bug and is now fixed ;)
// Before
declare module "classnames" {
export default function classnames(
...inputs: (string | number | false | object | undefined)[]
): string;;
}
// After
declare module "classnames" {
export default function classnames(
...inputs: (string | number | false | object | undefined)[]
): string;
}Adding a comment before a method used to take into account the comment length and would often expand the method when it wasn't expected. Thankfully, it was a simple fix, just wrap the output in a group.
// Before
interface TimerConstructor {
// Line-splitting comment
new (
interval: number,
callback: (handler: Timer) => void
): Timer;
}
interface TimerConstructor {
// Line-splitting comment
new (interval: number, callback: (handler: Timer) => void): Timer;
}This bug was very annoying if you ran into it: anytime you formatted the code, it would add one more _ to the object key!
// Before
obj = {
__: 42
___: 42
};
// After
obj = {
_: 42
__: 42
};Unlike in JavaScript, TypeScript lets you extend multiple classes at once. It turns out that people use this feature and prettier now does a better job at printing it.
// Before
export interface ThirdVeryLongAndBoringInterfaceName extends AVeryLongAndBoringInterfaceName, AnotherVeryLongAndBoringInterfaceName, AThirdVeryLongAndBoringInterfaceName {}
// After
export interface ThirdVeryLongAndBoringInterfaceName
extends AVeryLongAndBoringInterfaceName,
AnotherVeryLongAndBoringInterfaceName,
AThirdVeryLongAndBoringInterfaceName {}This one isn't very interesting, it's an edge case that's not properly handled in the TypeScript -> estree conversion.
// Before
call(c => { bla: 1 }) || [];
// After
call(c => ({ bla: 1 })) || [];By supporting TypeScript, prettier is now being used in a lot of Angular codebases which exercises edge cases that were not properly handled. In this case, we didn't preserve empty lines after directives inside of a function.
// Before
export default class {
constructor($log, $uibModal) {
"ngInject";
Object.assign(this, { $log, $uibModal });
// After
export default class {
constructor($log, $uibModal) {
"ngInject";
Object.assign(this, { $log, $uibModal });This release is very light in terms of JavaScript changes, which is awesome. We're starting to see the light at the end of the tunnel and get towards a great pretty printer. We're never going to get to a 100% perfect automatic pretty printer. The goal is that for every issue we get, there are no clear ways to improve the way it is printed without regressing other pieces.
The goal of prettier is to have a consistent way to format your code: given an AST, we always print the same way. In two places we had to compromise and read the original format: JSX and Objects. With this change, we're no longer relying on the original input for JSX with text inside. This lets us reflow
// Before
const Abc = () => {
return (
<div>
Please state your
{" "}
<b>name</b>
{" "}
and
{" "}
<b>occupation</b>
{" "}
for the board of directors.
</div>
);
};
// After
const Abc = () => {
return (
<div>
Please state your <b>name</b> and <b>occupation</b> for the board of
directors.
</div>
);
}Printing member chains is the most complicated piece of prettier and we keep finding small tweaks we can do to make it a better experience.
// Before
nock(/test/)
.matchHeader("Accept", "application/json")[httpMethodNock(method)]("/foo")
.reply(200, {
foo: "bar",
});
// After
nock(/test/)
.matchHeader("Accept", "application/json")
[httpMethodNock(method)]("/foo")
.reply(200, {
foo: "bar",
});Up until recently we haven't done much to support printing multiple variables in a single declaration as the most common practice is to do one variable declaration per variable. For single declarations, we don't want to indent it, but it turns out that we do when there are other ones afterwards, otherwise it looks weird.
// Before
var templateTagsMapping = {
'%{itemIndex}': 'index',
'%{itemContentMetaTextViews}': 'views'
},
separator = '<span class="item__content__meta__separator">•</span>';
// After
var templateTagsMapping = {
'%{itemIndex}': 'index',
'%{itemContentMetaTextViews}': 'views'
},
separator = '<span class="item__content__meta__separator">•</span>';This one is an unfortunate regression from 1.4 where we inlined import that only contained a single element. Turns out the definition of a single element allowed a single type and a single element. This is now corrected!
// Before
import transformRouterContext, { type TransformedContextRouter } from '../../helpers/transformRouterContext';
// After
import transformRouterContext, {
type TransformedContextRouter
} from '../../helpers/transformRouterContext';The goal of prettier is to format code people write in practice, so we enable loose/experimental modes for all the parsers we support. Babylon allows you to write import within a function, which is not part of the standard, but it doesn't cost us much to allow it.
// Before
ParseError
// After
function f() {
import x from 'x';
}We keep adding features for function calls and have to backport them to new calls as they have a different AST node type but in practice we want to treat them the same. This fix refactored the two so that they are going through the same call site, so hopefully should prevent more from sneaking in.
// Before
new Error(
formatErrorMessage`
This a really bad error.
Which has more than one line.
`
);
// After
new Error(formatErrorMessage`
This a really bad error.
Which has more than one line.
`);When we switched to using the same heuristic for assignment (a = b) for objects ({a: b}), we forgot to fix the indentation. Now it's fixed.
// Before
var abc = {
thing:
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf" +
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf" +
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf",
}
// After
var abc = {
thing:
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf" +
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf" +
"asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf",
}Prettier already had a special case when the expression was a conditional but it didn't apply when the conditional was the left part of a ternary. Now it does.
// Before
room = room.map((row, rowIndex) =>
row.map(
(col, colIndex) =>
rowIndex === 0 ||
colIndex === 0 ||
rowIndex === height ||
colIndex === width
? 1
: 0
)
);
// After
room = room.map((row, rowIndex) =>
row.map(
(col, colIndex) =>
rowIndex === 0 ||
colIndex === 0 ||
rowIndex === height ||
colIndex === width
? 1
: 0
)
);With the 1.0 release, we fixed a bug in the printing that introduced an exponential behavior. We've been able to mitigate the biggest issue such that reasonable code didn't time out, but it wasn't completely fixed it. By adding a caching layer at the right spot, we should now be in the clear.
This should make printing the IR of prettier using prettier in debug mode no longer time out.
// Before
...times out...
// After
someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
return someObject.someFunction().then(function () {
anotherFunction();
});
});
});
});
});
});
});
});
});We refactored the code that prints modifiers when we introduced TypeScript support and accidentally moved around the variance (+) part before static which is not valid in Flow. This is now fixed.
// Before
class Route {
+static param: T;
}
// After
class Route {
static +param: T;
}Both those features were introduced in the last release and we discovered a bunch of issues when actually using them in production. A bunch of them got fixed, if you see more, please report them!
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
7 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
I want to give a special shout out to @azz who has been maintaining the repository and implementing a bunch of the changes in this release as I had less time to devote to prettier due to vacation and switching team :)
Since the very first release of prettier, people have asked for a .prettierrc file. We've been trying to have as few options as possible and tried to avoid being one more .dotfile that you have to have when starting a new project.
But, the truth is, we need to have some way to configure prettier that can be kept in sync with all the integrations. By not having one, we pushed the problem to them and saw a bunch of incompatible ways of handling the problem. So now, it's handled by prettier itself.
// .prettierrc
{
"trailingComma": "es5",
"singleQuote": true
}For more information on configuration file support, see the README.
Along with telling what configuration to use, you can write a file .prettierignore to tell which files not to convert.
# .prettierignore
dist/
package.json
The last big friction point from people trying to adopt prettier was around how JSX was being printed. We went through all the issues that were raised and made a bunch of changes:
// Before
const Component = props =>
<div>
Hello {props.name}!
</div>;
// After
const Component = props => (
<div>
Hello {props.name}!
</div>
);// Before
<div>
{props.isVisible
? <BaseForm
url="/auth/google"
method="GET"
/>
: <Placeholder />}
</div>;
// After
<div>
{props.isVisible ? (
<BaseForm
url="/auth/google"
method="GET"
/>
) : (
<Placeholder />
)}
</div>// Before
<div>
{props.isVisible &&
<BaseForm
url="/auth/google"
method="GET"
/>}
</div>;
// After
<div>
{props.isVisible && (
<BaseForm
url="/auth/google"
method="GET"
/>
)}
</div>Hopefully this is going to be more in line with how the majority of the community is writing JSX and we can have prettier be used in more place ;)
With JSX, we started by respecting a lot of line breaks that were in the original source. This had the advantage of doing fewer changes to your codebase but chipped away the value of a consistent pretty printer as the same semantic code could be written in two ways.
During each new release we've tightened this and made decisions around how to always print a piece of code. The latest of those is what happens if there's a single child in a JSX object, we're now always going to inline it.
// Before
return (
<div>
{this.props.test}
</div>
);
return <div>{this.props.test}</div>;
// After
return <div>{this.props.test}</div>;
return <div>{this.props.test}</div>;Leading JSX empty spaces are now on their own line. It looked weird to have them before a tag as it "indented" it differently compared to the rest.
// Before
<span className="d1">
{' '}<a
href="https://github.schibsted.io/finn/troika"
className="link"
/>
</span>
// After
<span className="d1">
{' '}
<a
href="https://github.schibsted.io/finn/troika"
className="link"
/>
</span>We used to use a strict JSON parser that would throw if there was a comment or a trailing comma. This was inconvenient as many JSON files in practice are parsed using JavaScript or json5 that are not as strict. Now, we have relaxed this and are using the JavaScript parser to parse and print JSON. This means that comments will be maintained if there were some.
Note that this is purely additive, if your original file was JSON compliant, it will keep printing a valid JSON.
// Before
Syntax error
// After
{ /* some comment */ "a": 1 }Parenthesis are a hot topic because they are not part of the AST, so prettier ignores all the ones you are putting and re-creating them from scratch. We went through all the things that people reported and came up with a few edge cases that were very confusing when comparisons were chained and % was mixed with * or /.
One thing that we are not changing is the fact that we remove extra parenthesis around combinations of basic arithmetic operators: +-*/.
// Before
x !== y === z;
x * y % z;
// After
(x !== y) === z;
(x * y) % z;It's useful to be able to ignore pieces of JSX, it's now possible to add a comment inside of a JSX expression to ignore the formatting of the next element.
// Before
<Component>
{/*prettier-ignore*/}
<span ugly format="" />
</Component>
// Before
<Component>
{/*prettier-ignore*/}
<span ugly format='' />
</Component>In order to support some edge cases, in the internals, we have the ability to avoid printing comments in a generic way and print them in the call site instead. It turns out that when we used prettier-ignore, we didn't print the comments at all! This is now fixed.
// Before
push(
<td> :)
</td>,
);
// After
push(
// prettier-ignore
<td> :)
</td>,
);It took 6 months for someone to report that do-while were broken when the while condition is multi-line, it confirms my hunch that this construct is not widely used in practice.
// Before
do {} while (
someVeryLongFunc(
someVeryLongArgA,
someVeryLongArgB,
someVeryLongArgC
)
);
// After
do {} while (
someVeryLongFunc(
someVeryLongArgA,
someVeryLongArgB,
someVeryLongArgC
)
);Another underused feature of JavaScript is sequence expressions. We used to do a bad job at printing them when they would go multi-line, this has been corrected :)
// Before
(a = b ? c : "lllllllllllllllllllllll"), (a = b
? c
: "lllllllllllllllllllllll"), (a = b ? c : "lllllllllllllllllllllll"), (a = b
? c
: "lllllllllllllllllllllll"), (a = b ? c : "lllllllllllllllllllllll");
// After
(a = b ? c : 'lllllllllllllllllllllll'),
(a = b ? c : 'lllllllllllllllllllllll'),
(a = b ? c : 'lllllllllllllllllllllll'),
(a = b ? c : 'lllllllllllllllllllllll'),
(a = b ? c : 'lllllllllllllllllllllll')We took the stance with prettier to remove all the trailing whitespaces. We used to not touch comments because it's user generated, but that doesn't mean that they should have whitespace :)
// Before
// There is some space here ->______________
// After
// There is some space here ->Our handling for comments inside of the class declaration was very naive, we would just move all the comments to the top. We now are more precise and respect the comments that are interleaved inside of decorators and around extends.
// Before
// A
// B
// C
@Foo()
@Bar()
class Bar {}
// After
// A
@Foo()
// B
@Bar()
// C
class Bar {}Bind expressions are being discussed at TC39 and we figured we could print it with prettier. We used to be very naive about it and just chain it. Now, we use the same logic as we have for method chaining with the . operator for it. We also fixed some edge cases where it would output invalid code.
// Before
observable::filter(data => data.someTest)::throttle(() =>
interval(10)::take(1)::takeUntil(observable::filter(data => someOtherTest))
)::map(someFunction);
// After
observable
::filter(data => data.someTest)
::throttle(() =>
interval(10)::take(1)::takeUntil(observable::filter(data => someOtherTest))
)
::map(someFunction);It's being discussed at TC39 to be able to make the argument of a catch(e) optional. Let's make sure we can support it in prettier if people use it.
// Before
Syntax error
// After
try {} catch {}Another new proposal being discussed at TC39 is an optional chaining syntax. This is currently a stage 1 proposal, so the syntax may change at any time.
obj?.prop // optional static property access
obj?.[expr] // optional dynamic property access
func?.(...args) // optional function or method callComments are tricky to get right, but especially when they have meaning based on where they are positioned. We're now special casing the way we deal with comments used as type cast for Closure Compiler such that they keep having the same semantics.
// Before
let assignment /** @type {string} */ = getValue();
// After
let assignment = /** @type {string} */ (getValue());It looks kind of odd to have a computed property lookup on the next line, so we added a special case to inline it.
// Before
data
[key]('foo')
.then(() => console.log('bar'))
.catch(() => console.log('baz'));
// After
data[key]('foo')
.then(() => console.log('bar'))
.catch(() => console.log('baz'));The flow team introduced two very exciting features under a new syntax. We now support them in prettier. I've personally been waiting for opaque types for a veerrryyyy long time!
// Before
Syntax error
// After
opaque type ID = string;
export type * from "module";We've been doing this on JavaScript objects since the early days of prettier but forgot to apply the same thing to Flow and TypeScript types.
// Before
type A = {
"string": "A";
}
// After
type A = {
string: "A";
}Oopsy, we were dropping the generic in this very specific case.
// Before
type myFunction = A => B;
// After
type myFunction = <T>(A) => B;Parenthesis... someday we'll get all of them fixed :)
// Before
const actionArray: () => void[] = [];
// After
const actionArray: (() => void)[] = [];TypeScript 2.5 RC was recently announced, allowing you to use the upcoming "optional catch binding" syntax in TypeScript, too.
// Before
namespace global {
export namespace JSX { }
}
// After
global {
export namespace JSX {}
}Thanks to the untyped and permissive nature of JavaScript, we've been able to concat undefined to a string and get some interesting code as a result. Now fixed for this case :)
// Before
<undefined.Author />
// After
<this.Author />We want to make sure that all the special cases that we added for JavaScript and Flow also work for TypeScript constructs. In this case, objects should also hug if they are wrapped in a as operator.
// Before
const state = JSON.stringify(
{
next: window.location.href,
nonce,
} as State
);
// After
const state = JSON.stringify({
next: window.location.href,
nonce,
} as State);Most of the time we add parenthesis for correctness but in this case, we added them for nothing, so we can just get rid of them and have a cleaner code :)
// Before
(<x>a) || {};
// After
<x>a || {};Yet another case of missing parenthesis. Thankfully we're getting very few of them nowadays and they are for extremely rare edge cases.
// Before
foo.bar as Baz = [bar];
// After
(foo.bar as Baz) = [bar];The declare keyword doesn't do anything for interface so we never put it there. However, it felt weird if you were in a declaration file and seeing everything have declare before it except for interfaces. So now we reprint declare if it was there in the first place.
// Before
interface Dictionary<T> {
[index: string]: T
}
// After
declare interface Dictionary<T> {
[index: string]: T
}In order to get a first version of CSS to ship, we kept string quotes as is. We are now respecting the singleQuote option of prettier. The difficulty here was to make sure that we output correct code for all the crazy escapes, unicode characters, emoji, special rules like charset which only work with double quotes...
// Before
div {
content: "abc";
}
// After
div {
content: 'abc';
}Another place where we can reuse the logic we've done for JavaScript to improve CSS printing.
// Before
border: 1px solid rgba(0., 0.0, .0, .3);
// After
border: 1px solid rgba(0, 0, 0, 0.3);I can never quite remember the rules behind quotes around attributes so we're now always putting quotes there.
// Before
a[id=test] {}
// After
a[id="test"] {}// Before
const header = css`.top-bar {background: black;margin: 0;position: fixed;}`
// After
const header = css`
.top-bar {
background: black;
margin: 0;
position: fixed;
}
`;styled-components has a lot of different variants for tagging template literals as CSS. It's not ideal that we've got to encode all those ways inside of prettier but since we started, might as well do it for real.
styled(ExistingComponent)`
css: property;
`;
styled.button.attr({})`
border: rebeccapurple;
`;The CSS parsers we use do not give us a 100% semantic tree: in many occasions they bail and just give us what is being entered. It's up to us to make sure we clean this up while maintaining correctness. In this case, we just printed spaces between selectors as is but we know it's correct to always replace it by a single space.
// Before
.hello
.how-you-doin {
height: 42;
}
// After
.hello .how-you-doin {
height: 42;
}I still have nightmares from dealing with BOM in a previous life. Thankfully, in 2017 it's no longer a big issue as most tooling is now aware of it. Thanks @azz for fixing an edge cases related to CSS parsing.
// Before
[BOM]/* Block comment *
html {
content: "#{1}";
}// After
[BOM]/* Block comment */
html {
content: "#{1}";
}If you tried to use the range formatting feature in a GraphQL file, it would throw an exception, now it properly worked again and only reformats the piece you selected.
.gql file extension to be parsed as GraphQL (#2357) by @rrdelaneyAt Facebook, we use .graphql extension but it looks like it's common to have .gql as well, doesn't cost a lot to support it in the heuristic that figures out what parser to use.
It was already possible to have multiple glob patterns but they would be additive, with this change, you can add a glob pattern to ignore some files. It should be very handy to ignore folders that are deeply nested.
prettier --write '{**/*,*}.{js,jsx,json}' '!vendor/**'This is a handy way of knowing if prettier would print a piece of code in a different way. We already had all the concepts in place, we just needed to wire them up correctly.
$ echo 'call ( ) ;' | prettier --list-different
(stdin)
$ echo $?
1greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
This release features some bugfixes and tweaks around JSX, TypeScript, CSS, and JavaScript formatting, as well as a couple new features.
We received a lot of community feedback about the changes we made to JSX formatting in the 1.6.0 release, and have made changes to bring formatting closer to community standards and expectations.
In 1.6.0, we added a second style for ternaries (conditional expressions, a ? b : c), based on a format popular in the community where parentheses are used to demarcate JSX content:
const DinnerOptions = ({ willEatMeat, willEatEggs, willEatVegetables }) => (
<div>
<div>Let's get some dinner...</div>
{willEatMeat ? (
<FullMenu />
) : willEatEggs ? (
<VegetarianMenu />
) : willEatVegetables ? (
<VeganMenu />
) : (
<BackupMenu />
)}
</div>
);Before this was added, prettier only formatted ternaries with one consistent style:
willEatMeat
? "Full Menu"
: willEatEggs
? "Vegetarian Menu"
: willEatVegetables ? "Vegan Menu" : "Backup Menu";In 1.6.0, we used the following heuristic to decide when to use the new "JSX mode ternaries":
We should print a ternary using JSX mode if:
* The ternary contains some JSX in it
OR
* The ternary appears inside of some JSX
However, this heuristic caused some unexpected formatting:
So, in 1.7.0, we have revised our heuristic to just be:
We should print a ternary using JSX mode if:
* The ternary contains some JSX in it
We hope that this change will result in fewer surprising ternaries.
A big thanks goes out to @duailibe who implemented this change in addition to several other JSX-related formatting issues that were reported.
We spent some time this release polishing our CSS formatting, and as part of that, @lydell did some work to normalize letter case.
So now, almost everything in CSS will print using lower case.
/* Before */
DIV.Foo {
HEIGHT: 12PX;
}
/* After */
div.Foo {
height: 12px;
}Don't worry, though – Prettier won't touch your $scss-variables, @less-variables, or FunctionNames(). Preprocess on!
There is a new option called --require-pragma (requirePragma via the API) which will change prettier's behavior so that it only reformats a file if it has a special "pragma" comment at the top of it, that looks like this:
/**
* @prettier
*/or
/**
* @format
*/This was @ajhyndman's idea and it was implemented by @wbinnssmith.
There was a bug in Prettier 1.6.1 where an error would be thrown while parsing any TypeScript using the never type, for example:
Observable.empty<never>();Also, Prettier 1.6.1 was incorrectly removing the declare keyword from enum declarations in *.d.ts files:
// In
declare const enum Foo {}
// Out
const enum Foo {}Both of these issues have been fixed. Thanks to @JamesHenry and @existentialism for these fixes which support our TypeScript community!
There is a new CLI option --config-precedence which configures how prettier should prioritize config sources. Valid values are:
cli-override (default) - CLI options take precedence over config file
file-override - Config file take precedence over CLI options
prefer-file - If a config file is found will evaluate it and ignore other CLI options. If no config file is found CLI options will evaluate as normal.
This option adds support to editor integrations where users define their default configuration but want to respect project specific configuration.
prettier.resolveConfig.syncPreviously, there was no way via the API to resolve configuration for a source file synchronously. Thanks to some new additions to cosmiconfig by @sudo-suhas, @ikatyang was able to add support for this to the prettier API.
.sync() method by @ikatyangresolveConfigFile.sync() by @ikatyangcross-spawn by @ikatyangfiles: over types: in pre-commit configuration by @asottilequery) by @azz?: instead of ?! by @ikatyangdeclare modifier from enum reported by @mariusschulzThank you to everyone who contributed to this release, be it through issue creation, code contribution, code review, or general commenting and feedback. Prettier is a community-run project and is able to continue to exist thanks to people like you. Thank you!
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
This release adds Markdown support, a new --insert-pragma flag, fixes a number of formatting issues, adds support for some new experimental operators, and improves our editor integration support.
You can now run Prettier on Markdown files!
The implementation is highly compliant with the CommonMark spec, and backed by the excellent remark-parse package.
Word Wrap
One of Prettier's core features is its ability to wrap code at a specified line length. This applies to Markdown too, which means you can maintain nice and clean 80-character-wide Markdown files without having to re-adjust line breaks manually when you add or delete words.
Input:
Voilà! In view, a humble vaudevillian veteran cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valourous visitation of a bygone vexation stands vivified and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition! The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it's my very good honour to meet you and you may call me V.
Output:
Voilà! In view, a humble vaudevillian veteran cast vicariously as both victim
and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity,
is a vestige of the vox populi, now vacant, vanished. However, this valourous
visitation of a bygone vexation stands vivified and has vowed to vanquish these
venal and virulent vermin vanguarding vice and vouchsafing the violently vicious
and voracious violation of volition! The only verdict is vengeance; a vendetta
held as a votive, not in vain, for the value and veracity of such shall one day
vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage
veers most verbose, so let me simply add that it's my very good honour to meet
you and you may call me V.
Note for CJK users: If your markdown renderer does not support CJK line ending, you'll have to use plugin like markdown-it-perfect-newline-for-cjk, hexo-filter-fix-cjk-spacing, etc. to remove additional spaces.
// Source 一二三 四五六 七八九 // Rendered content with unsupported renderer 一二三 四五六 七八九 // Rendered content with supported renderer or via plugin 一二三四五六七八九
Code Formatting
Powered by Prettier's generic "multiparser", Prettier will format code blocks in Markdown! We use the language code provided with the code block to determine which language it is, and thus we can format any language that Prettier supports (including Markdown itself, if you're into that).
Input:
```js
reallyUgly (
javascript
)
```
```css
.h1 { color : red }
```Output:
```js
reallyUgly(javascript);
```
```css
.h1 {
color: red;
}
```Note: In some cases you may not want to format your code in Markdown, and just like in other languages, in Markdown you can use
<!-- prettier-ignore -->before the code block to ignore it from formatting.
Lists
When rearranging list items, after running Prettier all the numbers will be fixed!
Note: you can actually opt out of this by using
1.for all list items if you want to optimize for cleaner diffs.
Tables
Tables will also automatically be adjusted to fit their contents. This could be completely unmaintainable without an automated tool.
Markdown-in-JS
By using either md or markdown tagged template literals, you can format markdown code inside JavaScript.
const markdown = md`
# heading
1. list item
`;@format to first docblock if absent (#2865) by @samouriIn 1.7, we added an option called --require-pragma to require files contain an /** @format */ pragma to be formatted. In order to add this pragma to a large set of files you can now use --insert-pragma flag.
prettier --write "folder/**/*.js" --insert-pragma
--loglevel option (#2992) by @ikatyangThis nifty feature allows you to opt in (or out) of Prettier's logging. We've also cleaned up the logging substantially since 1.7.
$ prettier --loglevel=debug blarg
$ ./bin/prettier.js --loglevel=debug blarg
[debug] normalized argv: {"_":["blarg"],"bracket-spacing":false,"color":true,"debug-check":false,"debug-print-doc":false,"flow-parser":false,"insert-pragma":false,"jsx-bracket-same-line":false,"list-different":false,"require-pragma":false,"semi":false,"single-quote":false,"stdin":false,"use-tabs":false,"version":false,"with-node-modules":false,"write":false,"loglevel":"debug","ignore-path":".prettierignore","config-precedence":"cli-override"}
[error] No matching files. Patterns tried: blarg !**/node_modules/** !./node_modules/**
This has been a long-time known issue with Prettier. When formatting code that results in a change of indentation level, the JSDoc comments would end up being out of alignment. We're happy to report this is now fixed!
// Before
function theFunction2(action$, store) {
/*
* comments
*/
return true;
}
// After
function theFunction2(action$, store) {
/*
* comments
*/
return true;
}We've added support for two new proposed operators to Prettier: the pipeline operator and the nullish coalescing operator.
The pipeline operator is currently a stage one proposal.
This proposal introduces a new operator |> similar to F#, OCaml, Elixir, Elm, Julia, Hack, and LiveScript, as well as UNIX pipes. It's a backwards-compatible way of streamlining chained function calls in a readable, functional manner, and provides a practical alternative to extending built-in prototypes.
// Before
let result = exclaim(capitalize(doubleSay("hello")));
// After
let result = "hello"
|> doubleSay
|> capitalize
|> exclaim;The nullish coalescing operator is another stage one proposal.
When performing optional property access in a nested structure in conjunction with the optional chaining operator, it is often desired to provide a default value if the result of that property access is null or undefined.
This operator is similar to || except it only evaluates the right-hand-side if the left is undefined or null, not "", 0, NaN, etc.
const foo = object.foo ?? "default";This was another known issue with Prettier, when printing a template literal string with expressions inside that went over the print width, it would wrap the code in weird places inside the expressions. Now, if Prettier needs to insert a line break, it should happen right between ${ and }.
// Before
const description = `The value of the ${cssName} css of the ${this
._name} element`;
const foo = `mdl-textfield mdl-js-textfield ${className} ${content.length > 0
? "is-dirty"
: ""} combo-box__input`;
// After
const description = `The value of the \${cssName} css of the \${
this._name
} element`;
const foo = `mdl-textfield mdl-js-textfield ${className} ${
content.length > 0 ? 'is-dirty' : ''
} combo-box__input`} for arrow functions attributes (#3110) by @duailibeIn order to align closer to the Airbnb style guide, and since it was never intentionally printed this way, we've moved the } from to the next line in JSX. This is more diff friendly, and makes it easier to move code around by shifting lines in your editor.
// Before
<BookingIntroPanel
logClick={data =>
doLogClick("long_name_long_name_long_name", "long_name_long_name_long_name", data)}
/>;
// After
<BookingIntroPanel
logClick={data =>
doLogClick("long_name_long_name_long_name", "long_name_long_name_long_name", data)
}
/>;There was a bug in the heuristic that Prettier uses to determine whether an expression is a factory or not. It now works correctly with longer member expressions.
// Before
window.FooClient
.setVars({
locale: getFooLocale({ page }),
authorizationToken: data.token
})
.initVerify("foo_container");
// After
window.FooClient.setVars({
locale: getFooLocale({ page }),
authorizationToken: data.token
}).initVerify("foo_container");Printing comments in the right place is an endless challenge
// Before
function f(/* comment*/ promise) {}
// After
function f /* comment*/(promise) {}Member chains are one of the most complex parts of Prettier. This PR fixes an issue where repeated calls lead to the next method not being pushed to the next line.
// Before
wrapper
.find("SomewhatLongNodeName")
.prop("longPropFunctionName")().then(function() {
doSomething();
});
// After
wrapper
.find("SomewhatLongNodeName")
.prop("longPropFunctionName")()
.then(function() {
doSomething();
});Previously, Prettier would delete all newlines within a member chain. Now we keep up to one if it's in the source. This is nice for fluent APIs that you want to break up over multiple lines.
angular
.module("AngularAppModule")
// Constants.
.constant("API_URL", "http://localhost:8080/api")
// App configuration.
.config(appConfig)
.run(appRun);This addresses an issue where due to our special object inline behaviour, the indentation missing from the function call.
// Before
db.collection("indexOptionDefault").createIndex({ a: 1 },
{
indexOptionDefaults: true
},
function(err) {
// code
});
// After
db.collection("indexOptionDefault").createIndex(
{ a: 1 },
{
indexOptionDefaults: true
},
function(err) {
// code
}
);Similarly, there was another edge case where indentation was missing from logical expressions. This is fixed, too.
// Before
const someLongVariable = (idx(
this.props,
props => props.someLongPropertyName
) || []
).map(edge => edge.node);
// After
const someLongVariable = (
idx(this.props, props => props.someLongPropertyName) || []
).map(edge => edge.node);There are so many ways to break a line. Some of them look much worse than others. Breaking between in this case looked really weird, so it has been fixed!
// Before
function functionName() {
if (true) {
this._aVeryLongVariableNameToForceLineBreak = new this
.Promise((resolve, reject) => {
// do something
});
}
}
// After
function functionName() {
if (true) {
this._aVeryLongVariableNameToForceLineBreak = new this.Promise(
(resolve, reject) => {
// do something
}
);
}
}In a method chain we split lines by grouping elements together and accessing an array should be printed in the end of a group instead of the beginning.
// Before
find('.org-lclp-edit-copy-url-banner__link')
[0].getAttribute('href')
.indexOf(this.landingPageLink)
// After
find('.org-lclp-edit-copy-url-banner__link')[0]
.getAttribute('href')
.indexOf(this.landingPageLink)This was a minor alignment bug in intersection types, and has now been fixed.
// Before
type intersectionTest = {
propA: X
} & {
propB: X
} & {
propC: X
} & {
propD: X
};
// After
type Props = {
propA: X
} & {
propB: X
} & {
propC: X
} & {
propD: X
};We missed a case where we need to keep the parenthesis with TypeScript's as assertions. This is now fixed.
// Before
aValue as boolean ? 0 : -1;
// After
(aValue as boolean) ? 0 : -1;This fixes up the issue where JSX formatting occasionally needed to be run twice to become stable. This occurred when you had multiple JSX whitespace elements or JSX whitespace followed by a space.
// Before
<div>
{" "} <Badge src={notificationIconPng} />
</div>;
// After
<div>
{" "}
<Badge src={notificationIconPng} />
</div>This was an issue with the --jsx-bracket-same-line option. Turns out you can't always put the bracket on the same line...
// Input
<div
// comment
>
{foo}
</div>
// Before
<div>
// comment
{foo}
</div>;
// After
<div
// comment
>
{foo}
</div>;Prettier will now preserve line breaks included in the source code when formatting the grid and grid-template-* rules, since those are important to keep in separate lines, but still applies the formatting like other rules (e.g., numbers and quotes).
/* Original Input */
div {
grid:
[wide-start] 'header header header' 200.000px
[wide-end] "footer footer footer" .50fr
/ auto 50.000px auto;
}
/* Before */
div {
grid: [wide-start] "header header header" 200px [wide-end]
"footer footer footer" 0.5fr / auto 50px auto;
}
/* After */
div {
grid:
[wide-start] "header header header" 200px
[wide-end] "footer footer footer" 0.5fr
/ auto 50px auto;
}Turns out SCSS maps are much prettier when printed over multiple lines.
// Before
$map: (color: #111111, text-shadow: 1px 1px 0 salmon)
// After
$map: (
color: #111111,
text-shadow: 1px 1px 0 salmon
);Prettier will now format the CSS in styled-components code that looks like this:
styled(Component).attrs({})`
color: red;
`;Prettier doesn't support formatting JavaScript expressions in GraphQL. See #2640 for tracking. There was a bug where formatting an expression lead to invalid code, so we've completely disabled formatting GraphQL when it contains JavaScript expressions until we fully support it.
// Before
(invalid code)
// After
graphql(schema, `{ query test { id }} ${fragment}`)Previously, piping the output of --list-different to other tools was troublesome due to the ANSI color codes we use to show whether a file was modified or not. This PR disables the use of color when Prettier is piped to a different process.
This fixes a bug where passing a path starting with ./ to the CLI wouldn't match patterns used in .prettierignore.
# .prettierignore
path/to/*.js
After this fix, no files will be written to when executing:
$ prettier --write ./path/to/*.jsThis fixes an issue where .prettierrc overrides, under certain conditions, were not being respected for absolute paths with the resolveConfig API.
Chinese, Japanese and Korean characters are now considered two characters wide.
// Before (exceeds print width when CJK characters are 2x monospace chars)
const x = ["中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文"];
// After
const x = [
"中文",
// ...
"中文"
];#3015 also ensures that combining characters (e.g. Á) are counted as one character.
We've added a new function to the API (prettier.getSupportInfo([version])), and the CLI --support-info. This can be used to interrogate Prettier to find out which languages the current version, or an older version, supports. It also provides useful information such as CodeMirror IDs, tmScopes, etc, which can be used to automate some of the work done with lookup tables in text editor integrations.
Internally, we use this information to drive which extensions trigger which parsers, and support some common files that don't have extensions, like .prettierrc, Jakefile, etc.
# prettier knows that this file is JSON now.
$ prettier --write .prettierrcThis fixes an issue in editors that support range formatting, where formatting an object would cause Prettier to crash.
Thanks to everyone who contributed to this release, as well as those who raised issues! Prettier has become a highly stable piece of software that a large amount of people trust with their code. We take that trust seriously, and fix rare issues that break code with the highest priority. We can't fix these issues if we don't know about them, so never be afraid to create an issue!
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
This release adds an option for arrow function parens in arguments, support for the new JSX fragment syntax (<>), support for .editorconfig files, and nice additions to our GraphQL and Markdown support.
When printing arrow functions, Prettier omitted parens around the arguments if they weren’t strictly necessary, like so:
// no parens
foo => {};
// parens
(foo: Number) => {};
// parens
({ foo }) => {}
// parens
(foo = 5) => {}This lead to the most commented thread in our issue tracker. Prettier now has the --arrow-parens option (arrowParens in the config) that can assume two values today:
"avoid" - (default) preserve the behavior that omits parens when possible"always" - always includes parensPrettier will now recognize and format JSX with the new fragment syntax, like the code below:
function MyComponent() {
return (
<>
<Children1 />
<Children2 />
<Children3 />
</>
);
}We received feedback that formatting a JSX file with a really long text (~1000 lines) was really slow and noticed there was two performance bottlenecks in our fill primitive, which prints text until it reaches the print width and then insert a line break.
After the release of our Markdown support, we received feedback that breaking text to respect the print width could affect some renderers that could be sensitive to line breaks. In 1.8.2 we released a new option proseWrap: false that would print a paragraph in a single line, and users would rely on the "soft wrapping" feature of editors.
In 1.9 we are releasing a new option proseWrap: "preserve" which will respect the original line breaks of text, and lets the users decide where the text should break.
[WARNING] proseWrap with boolean value is deprecated, use "always", "never" or "preserve" instead.
[BREAKING CHANGE] proseWrap option now defaults to "preserve" as some renderers are linebreak-sensitive.
When GraphQL support was released, Prettier did not support interpolation so it would skip formatting if any interpolations were present, because interpolations make formatting very difficult. While that works well for the most part, users of the Apollo Client were missing out on Prettier’s GraphQL support sometimes, because Apollo Client uses interpolation to share fragments between queries. The good news is that only top-level interpolations are allowed, and that was way easier to add support for in Prettier.
In 1.9 we format GraphQL queries with top-level interpolation:
gql`
query User {
user(id: "Bob") {
...UserDetails
}
}
${UserDetailsFragment}
`(Prettier will continue to skip formatting if the interpolation is inside a query or mutation or so.)
Prettier will now respect intentional line breaks inside GraphQL queries (but limit to 1), where before it would remove them.
query User {
name
age
}CSS is mostly case insensitive, so Prettier has been lowercasing stuff for a while to keep things consistent. Turns out we overlooked a detail in the CSS spec. Element and attribute names in selectors depend on the markup language: In HTML they are case insensitive, but in SVG (XML) they are not. Previously Prettier would incorrectly lowercase element and attribute names, but now we don’t anymore.
It's taken a while, but Prettier will finally respect your .editorconfig file. This includes:
indent_styleindent_size/tab_widthmax_line_lengthThe prettier CLI respects .editorconfig by default, but you can opt out with --no-editorconfig.
However, the API doesn't respect .editorconfig by default, in order to avoid potential editor integration issues (see here for details). To opt in, add editorconfig: true to the prettier.resolveConfig options.
Prettier won't break an element with no attributes anymore, keeping elements like <br /> as an unit.
In the previous release we tried a new strategy of breaking template literals with expressions inside to respect the print width. We've received feedback that for some cases it was actually preferred that it would exceed print width than breaking in multiple lines.
From now on, template literals expressions that contain a single identifier won't break anymore:
const foo = `Hello ${username}. Today is ${month} ${day}. You have ${newMessages} new messages`.Fixes an edge case where Prettier was moving comments around breaking tools like Webpack:
const API = {
loader: () => import('./test' /* webpackChunkName: "test" */),
};
// would get formatted to
const API = {
loader: (/* webpackChunkName: "test" */) => import("./test")
};There was a case where comments between a decorator and a class property were moved to an invalid position.
// Before
class Something {
@decorator
static // comment
property = 1;
}
// After
class Something {
@decorator
// comment
static property = 1;
}It won't break empty type parameters (foo: Type<>) anymore.
We were accidentally dropping flow mixins, this has been fixed, but only for the babylon parser.
// Before
class Foo extends Bar {}
// After
class Foo extends Bar mixins Baz {}This was inconsistent with JavaScript and Flow, Prettier won't print a trailing comma in the following cases, when using the TypeScript parser:
const {
bar,
baz,
...rest
} = foo;We were omitting parens around type assertions inside decorators:
@(bind as ClassDecorator)
class Decorated {}inlineCode (#3230) by @ikatyangPrettier won't break text inside inlineCode meaning it will only break of after it.
Fixes cases where Prettier would insert extra whitespace like in the following examples:
扩展运算符（spread ）是三个点（`...`）。
This is an english paragraph with a CJK quote " 中文 ".Fixes the case where \_\_text\_\_ would be formatted as __text__.
Prettier now considers not only ASCII punctuation characters but Unicode as well.
We already supported YAML in the front matter of Markdown files and we added the TOML format as well, since some static site generators support it.
+++
date: '2017-10-10T22:49:47.369Z'
title: 'My Post Title'
categories: ['foo', 'bar']
+++
This is the markdown body of my post.Fixes a bug where it would indent lines after a list when it shouldn't:
* parent list item
* child list item
* [x] parent task list item
* [x] child task list itemwould become:
* parent list item
* child list item
* [x] parent task list item
* [x] child task list itemNon-breaking whitespaces are useful to keep words separated by spaces together in the same line (i.e. number and units or multi-word product names). Prettier was wrongfully converting them to regular whitespaces.
Fixes a bug where Prettier could break text if it went over the print width right before a number followed by . which would be parsed as a numbered list:
She grew up in an isolated village in the 19th century and met her father aged
29. Oh no, why are we in a numbered list now?Prettier will omit the semicolon (before and after) inside code samples if it's a simple JSX expression:
No semi:
```jsx
<div>Example</div>
```greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
greenkeeper[bot]
commented
6 years ago Your tests are still failing with this version. Compare the changes 🚨
Version 1.3.0 of prettier just got published.
This version is covered by your current version range and after updating it in your project the build failed.
As prettier is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.
I recommend you give this issue a high priority. I’m sure you can resolve this :muscle:
Status Details
- ❌ **continuous-integration/travis-ci/push** The Travis CI build failed [Details](https://travis-ci.org/tdeekens/tamesy/builds/228140861?utm_source=github_status&utm_medium=notification)Release Notes
1.3.0Facebook Adoption Update
The reason why I (@vjeux) embarked on this journey working on prettier has always been to get the entire Facebook codebase converted over. I would like to give an update on how it is going and what is the process to get there.
The first projects to adopt prettier were Jest, React and immutable-js. Those are small codebases in the order of hundreds of files that have their own infrastructure. There are 5 or less people working on them full time.
Then, Oculus and Nuclide converted their codebase over. The scale is bigger with a few thousands of files and tens of full time contributors but looks pretty similar to the first projects. The conversions went in one big codemod and that's it.
Now, the entire Facebook codebase is way bigger than this and it's not feasible to just convert everything in one go and to convince everyone that their entire codebase is going to be reformatted under their feet. So we need to find a more incremental approach.
Scaling adoption
Running prettier on a piece of code is a pretty expensive operation, it makes your pull request look bad because of a lot of unrelated changes and it causes merge conflicts for all the outstanding pull requests. So once a file has been formatted, you should do everything to make sure it remains formatted.
@formatto the first block comment like@flow.@formatis present.@formatto the header.@formatheader.@formatis in the header.@formatin order to avoid getting warnings afterwards.@formatover time.We finally got all those things wired up 1.5 weeks ago and the reception has been insane. Many people from various teams converted their codebase to prettier on their own. As of today, 15% of Facebook codebase has been converted over!
When I started working on prettier, I had a hunch that people were hungry for tools to solve formatting. But I had no idea that once the tooling was in place, people would rush to convert their codebase over! This is great confirmation that this project is useful to people and not just a gimmicky tool.
TypeScript Support Progress
@despairblue, @azz and @JamesHenry have been hard at work around getting TypeScript supported by prettier as it's the top requested feature. 2000 out of 11000 files in the TypeScript test suite are not yet properly printed. You can follow progress on #1480 and do not hesitate to help out!
Flow
Add trailing commas on flow generics (#1381)
The
--trailing-comma=alloption is supposed to add trailing commas everywhere possible, but as an oversight we forgot to do it for flow generics.Inline nullable in flow generics (#1426)
The phase after printing things correctly is to tweak the output to make it closer to the way people write code in practice. Inlining optional flow types is a small thing that makes a difference.
Allow flow declarations to break on StringLiteralTypeAnnotations (#1437)
We can always find more places to add breaks when things don't fit 80 columns. This time it's around declaring a type as a constant string.
Add space around
=for flow generics default arguments (#1476)Another example of small thing where we can improve the display of flow code. For function default arguments we put a space around
=but didn't around flow generics.Don't break for unparenthesised single argument flow function (#1452)
I'm trying to figure out something to write here, but ... it just looks weird!
Fix optional flow parenthesis (#1357)
We were a bit too lenient around parenthesis for optional flow types. In one case in the entire Facebook codebase, it generated code with different semantics. As part of this fix, we hardened the list of types that can be written without parenthesis.
Skip trailing commas with FlowShorthandWithOneArg (#1364)
It is a parse error to add a trailing comma without parenthesis for arguments of arrow function types. We found one case in Facebook codebase when this happened, it's a very rare occurrence.
Reorder flow object props (#1451)
This one is an example where the way the AST is structured is not our favor. Instead of having a list of elements inside of a type, the AST is structured in a way where normal keys and array keys each have their own group. In order to restore the initial order, we're now reading from the original source :(
Template Literal
Proper indentation for template literals (#1385)
A long standing issue with template literals and prettier is around the indentation of code inside of
${}. It used to be the indentation of the backtick but turned out to give poor results. Instead people tend to use the indent of the${. We changed this behavior and it magically made GraphQL queries look pretty!Do not indent calls with a single template literal argument (#873)
Template literals are very hard to deal with for a pretty printer because the spaces inside are meaningful so you can't re-indent them. We didn't know what to do for a call with a single template literal so we didn't do anything, but we kept receiving reports of people saying that prettier indented it the wrong way, so we are now inlining them. Fingers crossed it is going to cover most use cases.
Fix windows line ending on template literals (#1439)
We manipulate line endings in a lot of places in prettier and took great care of handling both
\nand\r\nexcept for template literals where we forgot. Now this is fixed!Inline template literals as arrow body (#1485)
We already inline template literals that are tagged (eg
graphql`query`) but didn't for plain template literals. For the anecdote, it turns out the code was supposed to support it but it was usingTemplateElementinstead ofTemplateLiteral:(Ternaries
Add parenthesis for unusual nested ternaries (#1386)
While working on printing nested ternaries, everyone focused on the ones with the shape of an if then else
cond1 ? elem1_if : cond2 ? elem2_if : elem_elsewhich is the most common. But, if you move move some?and:around you can have another pattern. It looks almost the same but has a different meaning. In order to reduce confusion, we're adding parenthesis around the uncommon form.Only add parenthesis on ternaries inside of arrow functions if doesn't break (#1450)
There's an eslint rule
no-confusing-arrowswhich suggests adding parenthesis for ternaries in arrow functions without brackets.It makes sense when code is in one line, but when it is split into multiple lines, the parenthesis are unnecessary given the indentation, so we now only put them when they serve their disambiguation purpose.
General JavaScript Improvements
Inline function declaration with single arg as object (#1173)
This one was often requested for React Stateless Functional Components (SFC). If you make use of a lot of them, it's likely going to be a big change for you.
Break inline object first in function arguments (#1453)
One thing we discovered early on is that people usually break the arguments of the function before breaking the return type. Unfortunately, the code responsible to inline single destructuring argument broke that assumption and it introduced bad looking code like this example. The good news is that it enables us to turn on inlining for single arguments that are typed with an object.
Don't break on empty arrays and objects (#1440)
This one has been a long standing issue and is an easy fix, but was an invaluable tool: whenever someone reported that
[]or{}would break, we were able to fix the example by fixing something else. So it was a great way to surface edge cases. Fortunately, this vein has now ran out and all the recent examples just look bad with no other reason than the fact that they are breaking. So it's time to finally do it!Do not break on [0] (#1441)
We have a lot of issues where code breaks in array access when it doesn't look good. We don't yet have a good generic solution for it, but we can add a specific fix a common situation:
[0].Indent do while condition (#1373)
We were not using the correct indentation logic for do-while condition but someone noticed, now we do!
Preserve inline comment as last argument (#1390)
We forgot to add one case in the comment detection code when they appear last for JSX attributes and function arguments which made them go after the closing. In the case of JSX, it generated code that had a different meaning. Fortunately, since we don't usually commit commented out code it didn't affect production code, but it is not a good experience while coding.
Break class expression returned by arrow call (#1464)
In 1.0, we made class be inline inside of arrow functions. It turns out that it doesn't work great when the class is non trivial, so we are reverting this change. We're trying really hard to avoid making trashy decisions like this where the style changes back and forth, but we allow ourselves to do it sometimes to fix mistakes!
Fix empty line in block with EmptyStatement (#1375)
This one was found by fuzzing. You're unlikely going to hit this in real code but it's good to know it is fixed!
Commits
The new version differs by 48 commits0.
a81d5c11.3.00785726Inline template literals as arrow body (#1485)f59aeefBreak inline object first in function arguments (#1453) (#1173)8f9bb3aBreak inline object first in function arguments (#1453)54b8cacReorder flow object props (#1451)c99a877Do not break on [0] (#1441)acfb14fDon't break on empty arrays and objects (#1440)bafd724Don't break for unparenthesised single argument flow function (#1452)a335c26Add space around=for flow generics default arguments (#1476)4b7d265Fix windows line ending on template literals (#1439)e392093Only add parenthesis on ternaries inside of arrow functions if doesn't break (#1450)93cad97Preserve inline comment as last argument (#1390)314e963Add parenthesis for unusual nested ternaries (#1386)13f05fbProper indentation for template literals (#1385)c521406[RFC] Do not indent calls with a single template literal argument (#873)There are 48 commits in total.
See the full diff
Not sure how things should work exactly?
There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html) and of course you may always [ask my humans](https://github.com/greenkeeperio/greenkeeper/issues/new).Your Greenkeeper Bot :palm_tree: