-
Notifications
You must be signed in to change notification settings - Fork 14
An in-range update of prettier is breaking the build 🚨 #42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
After pinning to 1.4.4 your tests are still failing. The reported issue might not affect your project. These imprecisions are caused by inconsistent test results. |
Version 1.5.1 just got published.Your tests are still failing with this version. Compare the changes 🚨 |
Version 1.5.2 just got published.Your tests are still failing with this version. Compare the changes 🚨 |
Version 1.5.3 just got published.Your tests are still failing with this version. Compare the changes 🚨 |
Version 1.6.0 just got published.Your tests are still failing with this version. Compare the changes 🚨 Release Notes1.6.0: Config File, JSXI 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 :) HighlightsConfigurationImplement cosmiconfig for workspace configuration (#2434) by @azzSince the very first release of prettier, people have asked for a 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. Support .prettierignore files (#2412) by @evilebottnawiAlong with telling what configuration to use, you can write a file
JSXImprove JSX Formatting (#2398) by @suchipiThe 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>;
// Before <div> {props.isVisible ? <BaseForm url="/auth/google" method="GET" /> : <Placeholder />} </div>;
// Before <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 ;) Inline single expressions in JSX (#2442) by @karlWith 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>; Ensure there is a line break after leading JSX white space (#2348) by @karlLeading 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> Other ChangesJSONUse babylon.parseExpression for JSON (#2476) by @josephfrazierWe 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 JavaScriptAdd more supervisory parens (#2423) by @azzParenthesis 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 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; Implement prettier-ignore inside JSX (#2487) by @azzIt'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> Do not swallow prettier-ignore comments (#2664)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 // Before push( <td> :) </td>, ); Fix indentation of a do-while condition (#2359) by @jsnajdrIt 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 ) ); Break sequence expressions (#2388) by @bakkotAnother 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"); Trim trailing whitespace from comments (#2494) by @azzWe 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 ->______________ Fix interleaved comments in class decorators (#2660, #2661)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 // Before // A // B // C @Foo() @Bar() class Bar {} Improve bind expression formatting (#2493) by @azzBind 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 // Before observable::filter(data => data.someTest)::throttle(() => interval(10)::take(1)::takeUntil(observable::filter(data => someOtherTest)) )::map(someFunction); Add support for printing optional catch binding (#2570) by @existentialismIt's being discussed at TC39 to be able to make the argument of a // Before Syntax error Add support for printing optional chaining syntax (#2572) by @azzAnother 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 call Handle Closure Compiler type cast syntax correctly (#2484) by @yangsuComments 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(); Inline first computed property lookup in member chain (#2670) by @azzIt 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')); FlowSupport opaque types and export star (#2543, #2542) by @existentialismThe 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 Strip away unnecessary quotes in keys in type objects and interfaces (#2643)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"; } Print TypeParameter even when unary function type (#2406) by @danwangOopsy, we were dropping the generic in this very specific case. // Before type myFunction = A => B; Keep parens around FunctionTypeAnnotation inside ArrayTypeAnnotation (#2561) by @azzParenthesis... someday we'll get all of them fixed :) // Before const actionArray: () => void[] = []; TypeScriptSupport TypeScript 2.5 RC (#2672) by @azzTypeScript 2.5 RC was recently announced, allowing you to use the upcoming "optional catch binding" syntax in TypeScript, too. 🎉 Don't add namespace keyword to global declaration (#2329) by @azz// Before namespace global { export namespace JSX { } } Fix <this.Component /> (#2472) by @backusThanks 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 /> Allow type assertions to hug (#2439) by @azzWe 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 // Before const state = JSON.stringify( { next: window.location.href, nonce, } as State ); Remove parens for type assertions in binary expressions (#2419) by @azzMost 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) || {}; Print parens around type assertion as LHS in assignment (#2525) by @azzYet 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]; Print declare for TSInterfaceDeclaration (#2574) by @existentialismThe // Before interface Dictionary<T> { [index: string]: T } CSSNormalize quotes in CSS (#2624) by @lydellIn order to get a first version of CSS to ship, we kept string quotes as is. We are now respecting the // Before div { content: "abc"; } Normalize numbers in CSS (#2627) by @lydellAnother 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); Quote unquoted CSS attribute values in selectors (#2644) by @lydellI can never quite remember the rules behind quotes around attributes so we're now always putting quotes there. // Before a[id=test] {} Add support for css keyword (#2337) by @zanza00// Before const header = css`.top-bar {background: black;margin: 0;position: fixed;}` Support styled-components with existing component (#2552, #2619) by @azzstyled-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; `; Trim whitespace in descendant combinator (#2411) by @azzThe 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 Strip BOM before parsing (#2373) by @azzI 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}"; } GraphQLAdd support for range-formatting GraphQL (#2319) by @josephfrazierIf 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. Add
|
Version 1.6.1 just got published.Your tests are still failing with this version. Compare the changes 🚨 |
Version 1.7.0 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 Release Notes1.7.0: JSX tweaks, Pragma, TypeScript and CSS fixesThis release features some bugfixes and tweaks around JSX, TypeScript, CSS, and JavaScript formatting, as well as a couple new features. HighlightsJSX ChangesWe 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, 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":
However, this heuristic caused some unexpected formatting: So, in 1.7.0, we have revised our heuristic to just be:
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. CSS Letter Case ConsistencyWe 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 /* Before */ DIV.Foo { HEIGHT: 12PX; } Don't worry, though – Prettier won't touch your Pragma SupportThere is a new option called /** * @prettier */ or /** * @format */ This was @ajhyndman's idea and it was implemented by @wbinnssmith. Other ChangesTypeScriptThere was a bug in Prettier 1.6.1 where an error would be thrown while parsing any TypeScript using the Observable.empty<never>(); Also, Prettier 1.6.1 was incorrectly removing the // In declare const enum Foo {} Both of these issues have been fixed. Thanks to @JamesHenry and @existentialism for these fixes which support our TypeScript community! ConfigurationConfigurable Config PrecedenceThere is a new CLI option
This option adds support to editor integrations where users define their default configuration but want to respect project specific configuration.
|
Version 1.7.1 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.7.2 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.7.3 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.7.4 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.8.0 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 Release Notes1.8.0: Markdown SupportThis release adds Markdown support, a new HighlightsMarkdown SupportSupport markdown (#2943) by @ikatyangYou can now run Prettier on Markdown files! 🎉 The implementation is highly compliant with the CommonMark spec, and backed by the excellent 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:
Output:
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 ) ``` |
Version 1.8.1 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.8.2 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.9.0 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 Release Notes1.9.0: JSX Fragments, EditorConfig and Arrow ParensThis release adds an option for arrow function parens in arguments, support for the new JSX fragment syntax ( HighlightsJavaScriptOption to add parens in arrow function arguments (#3324) by @rattrayalex and @suchipiWhen printing arrow functions, Prettier omitted parens around the arguments if they weren’t strictly necessary, like so: // no parens foo => {}; This lead to the most commented thread in our issue tracker. Prettier now has the
JSX fragment syntax (#3237) by @duailibePrettier will now recognize and format JSX with the new fragment syntax, like the code below: function MyComponent() { return ( <> <Children1 /> <Children2 /> <Children3 /> </> ); } Fix slow formatting long texts in JSX (#3268, #3273) by @duailibeWe 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 MarkdownAdd an option to preserve text line breaks (#3340) by @ikatyangAfter 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 In 1.9 we are releasing a new option [WARNING] [BREAKING CHANGE] GraphQLSupport top-level interpolations (#3370) by @lydellWhen 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.) Preserve intentional new lines in GraphQL (#3252) by @duailibePrettier will now respect intentional line breaks inside GraphQL queries (but limit to 1), where before it would remove them. query User { name CSSDon't lowercase element names and attribute names in selectors (#3317) by @lydellCSS 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. ConfigurationAdd EditorConfig support (#3255) by @josephfrazierIt's taken a while, but Prettier will finally respect your
The Other changesJavaScriptDon't break simple elements in JSX (#3250) by @duailibePrettier won't break an element with no attributes anymore, keeping elements like Don't break identifiers inside template literals expressions (#3299) by @duailibeIn 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`. Fix formatting of comment inside arrow function (#3334) by @jackyho112Fixes an edge case where Prettier was moving comments around breaking tools like Webpack: const API = { loader: () => import('./test' /* webpackChunkName: "test" */), }; Fix printing of comments around decorators and class properties (#3382) by @azzThere 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; } FlowDo not break on empty type parameters (#3281) by @vjeuxIt won't break empty type parameters ( Add support for flow mixins when using babylon (#3391) by @bakkotWe were accidentally dropping flow mixins, this has been fixed, but only for the // Before class Foo extends Bar {} TypeScriptDon't print a trailing comma after object rest spread (#3313) by @duailibeThis 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; Print parens around type assertions for decorators (#3329) by @azzWe were omitting parens around type assertions inside decorators: @(bind as ClassDecorator) class Decorated {} MarkdownDon't break
|
Version 1.9.1 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.9.2 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.10.0 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 Release Notes1.10: One Year of Prettier 🎂 |
Version 1.10.1 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.10.2 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.11.0 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 Release NotesPrettier 1.11: CSS fixes and new TypeScript feature support |
Version 1.11.1 just got published.Your tests are passing again with this version. Explicitly upgrade to this version 🚀 |
Version 1.12.0 just got published.Your tests are still failing with this version. Compare the changes 🚨 Release NotesPrettier 1.12: Fixes, Features, and Formatting, Oh My! |
Version 1.12.1 just got published.Your tests are still failing with this version. Compare the changes 🚨 |
Version 1.5.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 💪
Status Details
Release Notes
1.5.0: GraphQL, CSS-in-JS & JSONThis 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!
Blog Post: Adding a new layout strategy to Prettier by @karl
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.GraphQL
Thanks to @stubailo, @jnwng, @tgriesser and @azz, prettier now supports printing GraphQL queries!
It works for
.graphql
files and within JavaScipt templates that start withgraphql
,graphql.experimental
andgql
in order to work with Relay and Apollo.Note that it only supports the open source syntax of GraphQL, therefore doesn't work with Relay Classic, it only works with Relay Modern.
CSS-in-JS
If you are using styled-components or styled-jsx, prettier will now reformat the CSS inside of your template expressions.
JSON
This was pretty straightforward to implement but nonetheless very useful. Thanks to @josephfrazier for doing it :)
CSS
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.
CSS: Every selector is now printed in its own line (#2047) by @yuchi
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.CSS: lowercase hex colors (#2203) by @azz
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.CSS: Use fill for CSS values (#2224)
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.CSS: Allow long media rules to break (#2219)
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.CSS: Print @else on same line as } (#2088) by @azz
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.CSS: implement prettier-ignore (#2089) by @azz
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 :)CSS: Fix css-modules composes breaking with long line width (#2190) by @tdeekens
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 thecomposes
field, it doesn't recognize it anymore. So we're no longer breaking it there, even if it goes over 80 columns.CSS: First try scss when there's an @import with comma (#2225)
We made a decision to have only a single high level "parser" for CSS, SCSS and Less even though we are using
postcss-less
andpostcss-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.
TypeScript
TypeScript support is now solid, all the changes for this release are small edge cases.
TypeScript: print arrow function type params on same line as params (#2101) by @azz
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.TypeScript: keep parens around with yield/await non-null assertion (#2149) by @azz
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
!
.TypeScript: Print {} in import if it's in the source (#2150) by @azz
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.TypeScript: Always break interfaces onto multiple lines (#2161) by @azz
The code that implements
interface
is shared with the code that printsobject
s, 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.TypeScript: Fix extra semicolon in ambient typescript declaration emit (#2167) by @azz
no-semi
andsemi
are often requested but on the prettier team we're one step ahead and implementedtwo-semi
for you! Just kidding, it was a bug and is now fixed ;)TypeScript: group function params in call/construct signatures (#2169) by @azz
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
.TypeScript: Upgrade tsep (#2183) by @azz
This bug was very annoying if you ran into it: anytime you formatted the code, it would add one more
_
to the object key!TypeScript: break on multiple interface extends (#2085) by @azz
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.
TypeScript: handle ObjectPattern instead of ObjectExpression inside BinaryExpression (#2238) by @azz
This one isn't very interesting, it's an edge case that's not properly handled in the TypeScript -> estree conversion.
Preserve lines after directives (#2070)
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.
Not sure how things should work exactly?
There is a collection of frequently asked questions and of course you may always ask my humans.
Your Greenkeeper Bot 🌴
The text was updated successfully, but these errors were encountered: