A long time ago I introduced the ability to break for import statements. Then, later on, we removed the ability for require to break and go over the 80 column mark. In order to be consistent, we should do the same for import statements as well.
There can often be something that breaks inside of `extends` so it's looking weird to break twice. It now only breaks on `implements` and make sure to put each element on its own line.
Fixes#1520
I didn't intend for putting parenthesis there in the first place but it slept through. Since it was going to trigger a ton of changes I held up changing it, but I feel like we need to do it sooner than later otherwise we're not going to be able to do it. A lot of people writing functional components are going to be very happy about this change :)
TypeScript doesn't have the concept of `?` for nullable options and instead you have to write `| null` and `| void`. This is annoying to have it use the long form, so we're now inlining them.
While working on this, I found out a few issues with the way we deal with those:
- We only align objects if the parent is a union. This means that if you have `Array<{ object }>`, the object is not aligned properly. The fix is to move the alignment logic to the union, and not the child.
- When doing so, it messes up with the comment alignment, so we have to manually handle children comment printing in the union code.
It doesn't yet fix#1727 because the hardcoded type names are different, i'll follow up in a PR.
This keeps being requested and we're not using it at Facebook, so I don't particularly care which way it should be printed. We now force multiline if there's at least one declaration with a value. We don't want to break all the variables that are just declared.
Fixes#1607
We don't always want to automatically forward this option but we can always forward it to `n.body`. If it's an arrow function, it's doing the intended behavior, otherwise, it's not going to ignore it and not forward it. What we don't want is for arrow -> blockStatement -> arrow to get it, but we're good.
Fixes#1652
This makes it easier to search through the code without getting
irrelevant results. It uses a .ignore file in order to cover at least
the three tools mentioned in the title. See the discussion here:
https://news.ycombinator.com/item?id=12568822
I have no intention of using flow to type prettier but adding this file makes Nuclide run flow and get jump to definition and some datatips for what it can infer.
The function isPreviousLineEmpty comment doesn't skip comments (on purpose, see comment above that method :P) so the detection is messed up. Turns out, it's easier to just use isNextLineEmpty like everywhere else.
Fixes#1708
We completely butcher comments inside of template literals. The fix is to not be able to attach comments to TemplateExpression nodes and to avoid comments that are ine one expression to be moved to another expression. We now have the boundary to prevent outputting invalid code.
Fixes#1617
This is very unfortunate that we have to change the generic function that prints code but we want the JSXElement node to handle its comments printing itself in order to write them inside of the parenthesis instead of outside.
Fixes#555
I implemented indenting based on any character that's before the `${` but it was not the right behavior. Instead people want to indent based on the indentation of this line. It's easy to fix :)
Fixes parts of #1626
I wanted to see how hard it would be to add support for CSS inside of prettier. Turns out, it's not that hard. I spent a few hours printing post-css values and getting all the stylefmt unit tests to not throw.
I kept adding places where comments could be but more use cases kept creeping in. So now this is a holistical approach, we check all the comments that can be between two nodes. This way we should be good to go :)
Christopher Chedeau