--- author: Christopher Chedeau (@vjeux) authorURL: https://twitter.com/vjeux title: Releasing Prettier 1.0 --- _This post was written by [vjeux](https://twitter.com/vjeux) and edited by [jlongster](https://twitter.com/jlongster), and originally published [here](http://jlongster.com/prettier-1.0)_ We officially [announced](http://jlongster.com/A-Prettier-Formatter) [prettier](https://github.com/prettier/prettier) over two months ago as a way to solve the problem of wasting time formatting your code. It started as an experiment but it clearly resonated with a lot of people, amassing ~7000 GitHub stars and over 100,000 monthly `npm downloads` in just two months. In case you don't know, prettier is a JavaScript formatter that works by compiling your code to an AST, and then pretty-printing the AST. Like browsers wrap text, prettier will also wrap code according to a given line length. The result is good-looking code that is completely consistent no matter who wrote it. This solves the problem of programmers spending a lot of time manually moving around code in their editor and arguing about styles (see [gif](http://jlongster.com/s/refactor.gif)). It wasn't entirely clear from the beginning if we could make it always generate valid and good-looking code, but the good news is that this is no longer an open question. Many projects (React, Jest, immutable-js, Haul, and many more) and companies (Oculus, Cloudflare) adopted prettier to format their JavaScript codebase and realized the wins of automated formatting (see [this tweet](https://twitter.com/jlongster/status/852532847252566017) for more!). Some of them ran prettier on their entire codebase (tens of thousands of lines of code). During the past three weeks we went through all the open issues and tried to make as many decisions regarding how code is being formatted as possible and fixed most of the bugs we knew about. It's not perfect and we'll keep iterating on it but it's a good time to **release a 1.0**! This does not mean we won't change the format anymore, but changes will be minimal. For example, we are looking at adjusting [ternaries](https://github.com/prettier/prettier/pull/1171) but there will be very few changes of that nature from here on out, and when there are we will make a new major version. What it means is that **prettier is safe to use for production**. We've fixed a ton of bugs and made sure the output is stable and semantically correct. Prettier is ready to be used from a few files in your side project to converting your entire codebase. It's up to you to figure out where you are in the journey of letting go of a particular way to formatting your code. Let's take a look what 1.0 brings to [prettier](https://github.com/prettier/prettier)! _Thank you to all of the following contributors who have contributed to this release, and thank you to [Ian Storm Taylor](https://github.com/ianstormtaylor) for the logo!_ _Adam Stankiewicz, Alex Rattray, Alex Stachowiak, Amjad Masad, Andrey Okonetchnikov, António Nuno Monteiro, Artem Sapegin, Benjamin Tan, Bill Mill, Brandon Mills, Brian Holt, Brian Ng, Charles Pick, ChristianHersevoort, Christopher Chedeau, Christopher Moeller, Damien Lebrun, Dan Harper, Dara Hak, David Ascher, David Hong, Davy Duperron, Eric Clemmons, Erick Romero, Esben Petersen, Filipe Fortes, Gregor Adams, Hampus,hlsson, Hawken Rives, Henry Zhu, Ilya Panasenko, James Henry, James Long, Jamie Webb, Jan Kassens, Jed Watson, Jeffrey Horn, Jeremy Morrell, Joe Fiorini, Jon LaBelle, Joseph Savona, Karl Horky, Karl O'Keeffe, Kent C. Dodds, Kevin Gibbons, Kim Joar Bekkelund, Lucas Bento, Lucas Duailibe, MarekMatejkaKCL, Mateusz Zatorski, Michael Ficarra, Michał Pierzchała, Mikael Brevik, Nathan Friedly, Patrick Camacho, Paul,arduner, Rafael Hengles, Raghuvir Kasturi, Rasmus Eneman, Riley Tomasek, Rogelio Guzman, Royce Townsend, Sean Grove, Shigeaki Okazaki, Simen,ekkhus, Simon Lydell, Sorin Muntean, Spencer Dixon, Thai Pangsakulyanont, Tom McKearney, Travis Jefferson, Umidbek Karimov, Vincent Voyer, Vu Tran, Walter Breakell, Yatharth Khatri, azu, daleroy, kalmanb, skratchdot_ ## Options Prettier is an opinionated code formatter. At the beginning of the project, we thought that it meant having no configuration like gofmt or refmt. But, as we moved forward, we realized that this was going to hurt the adoption of prettier and people that would have benefited from it wouldn't use it because it wasn't printing code the way they want. Instead, our recent interpretation of being an opinionated code formatter is to provide options regarding basic aspects of the syntax that are of the nature of "if it doesn't do X, no matter how good it is, I'm never going to use it". For example, I (@vjeux) am never going to use [standard](https://github.com/feross/standard) because it doesn't use semi-colons. This is absolutely not a rational way to think about it, but that's the way many people behave and why we have "style wars". We are still not going to introduce options for every type of syntax, but only for more impactful things. We've identified two major options that fall in that category: _tabs vs spaces_ and _semi vs no-semi_. So we're adding them in prettier! ### --no-semi ([#1129](https://github.com/prettier/prettier/pull/1129)) Thanks to [rattrayalex](https://github.com/rattrayalex) who did a lot of work to make this happen! ```js // Before console.log(); [1, 2, 3].map(x => x + 1); // After console.log() ;[1, 2, 3].map(x => x + 1) ``` ### --use-tabs ([#1026](https://github.com/prettier/prettier/pull/1026)) Thanks to [rhengles](https://github.com/rhengles) for implementing this and explaining the reasons behind it! ```js // Before if (1) { ··console.log(); // Two spaces } // After if (1) { » console.log(); // One Tab! } ``` ## Formatting The rest of this post document all of the smaller changes that we round up for 1.0. We won't usually post a changelog as a post, but we thought that it shows how stable prettier is getting and gives a good sense for the kinds of issues we are fixing these days. ### Add newline for bracket-less arrow functions that return calls ([#927](https://github.com/prettier/prettier/pull/927)) Probably the most reported issue from the current version of prettier: we were not adding a newline after arrow functions inside of calls. Now, we do. On a side note, it's pretty exciting that the issues are now about small things like this and no longer "this looks completely broken" kind of issues. ```js // Before const testResults = results.testResults.map(testResult => formatResult(testResult, formatter, reporter)); // After const testResults = results.testResults.map(testResult => formatResult(testResult, formatter, reporter) ); ``` ### Add softline to assignment and parens around return for binary expressions ([#871](https://github.com/prettier/prettier/pull/871) & [#870](https://github.com/prettier/prettier/pull/870)) Big chains of logical expressions look weird when the first line is on the same line as the variable declaration or return. Instead, it's better to move it on the next line and add parenthesis in return to make it valid. ```js // Before const computedDescriptionLines = (showConfirm && descriptionLinesConfirming) || (focused && !loading && descriptionLinesFocused) || descriptionLines; // After const computedDescriptionLines = (showConfirm && descriptionLinesConfirming) || (focused && !loading && descriptionLinesFocused) || descriptionLines; // Before return !filePath.includes(coverageDirectory) && !filePath.endsWith(`.${SNAPSHOT_EXTENSION}`); // After return ( !filePath.includes(coverageDirectory) && !filePath.endsWith(`.${SNAPSHOT_EXTENSION}`) ); ``` ### Group first arg for inline functions ([#947](https://github.com/prettier/prettier/pull/947)) The first big custom pattern we've added in prettier is printing functions as last arguments inline. A less common one is to do the same thing for the first argument. It's very uncommon for libraries written nowadays to use that style but some core JavaScript functions like `setTimeout` are doing it so it makes sense to support it in prettier. ```js // Before setTimeout( function() { thing(); }, 500 ); // After setTimeout(function() { thing(); }, 500); ``` ### Improve jsx output for style components ([#1144](https://github.com/prettier/prettier/pull/1144)) Template literals are very tricky to format because whitespaces are significant. With prettier, we don't want to change the semantic of your program by reformatting it so we're leaving them as is. The current way we handle them is not optimal and we have ideas on how to fix them in a general way but in the meantime, we can do some targeted fixes like this one for JSX. ```jsx // Before // After ``` ### Add support for same line dot-notation in decorators ([#1029](https://github.com/prettier/prettier/pull/1029)) MobX 3 now uses member expressions that should be written inline, the previous heuristic was too restrictive. It is now fixed. ```js class X { // Before @action.bound setPrice(price) { this.price = price; } // After @action.bound setPrice(price) { this.price = price; } } ``` ### Hug on single object destructuring function ([#1022](https://github.com/prettier/prettier/pull/1022)) React stateless functional components are all the rage right now and it makes sense to hug the destructuring of the first argument to take less space. ```jsx // Before export default function StatelessFunctionalComponent( { searchFilters, title, items } ) { return
; } // After export default function StatelessFunctionalComponent({ searchFilters, title, items, }) { return } ``` ### Add support for currying ([#1066](https://github.com/prettier/prettier/pull/1066)) Redux is heavily promoting writing functions in a curried form where each argument is a nested function. Instead of indenting them, we're now putting them inline. ```js // Before const mw = store => next => action => { return next(action) }; // After const mw = store => next => action => { return next(action) }; ``` ### Respect escaping for JSX strings ([#1056](https://github.com/prettier/prettier/pull/1056)) For strings we've tried a bunch of different solutions regarding to escaping: escape nothing, escape everything, escape a whitelisted set... But we couldn't find a heuristic that would make all the use cases reasonable. So we decided to leave the strings escaped the way they were inputted. We're now doing this for JSX strings. ```jsx // Before // After ``` ## Parenthesis A blessing and curse of printing from the AST is that we have to reprint all the parenthesis of the program. Our stance used to be to print only the minimum number of parenthesis that were needed for the program to be valid and execute the same way. Now, we're willing to add parenthesis that are not strictly needed but help people understand the code. ### Add parenthesis for binary operators ([#1153](https://github.com/prettier/prettier/pull/1153)) ```js // Before var sizeIndex = index - 1 >>> level & MASK; // After var sizeIndex = ((index - 1) >>> level) & MASK; ``` ### Add parenthesis for no-confusing-arrow rule ([#1182](https://github.com/prettier/prettier/pull/1182)) ```js // Before var x = a => 1 ? 2 : 3; // After var x = a => (1 ? 2 : 3); ``` ### Remove parens from chained assignments ([#967](https://github.com/prettier/prettier/pull/967)) ```js // Before this.size = (this._origin = (this._capacity = 0)); // After this.size = this._origin = this._capacity = 0; ``` ## Flow In the early days of prettier we've heavily focused on getting the core JavaScript language well supported. Now that it is in a good shape, we have more time to print Flow constructs in a polished way. ### Add ability for flow generics to break ([#1041](https://github.com/prettier/prettier/pull/1041)) ```ts // Before type _ReactElement