prettier: Inconsistent formating for the same code

Hi everyone,

I’ve been playing with prettier (which is just amazing) on some of our project, and notice a behaviour that i found really strange, where the same code, can lead to four different formating :

Original code :

/* The 4 components are the same */

const Component1 = ({ props }) => (
  <Text>Test</Text>
);

const Component2 = ({
  props
}) => (
  <Text>Test</Text>
);

const Component3 = ({ props }) => (
  <Text>
  Test
  </Text>
);

const Component4 = ({
  props 
}) => (
  <Text>
  Test
  </Text>
);

Turns after prettier to :

const Component1 = ({ props }) => <Text>Test</Text>;

const Component2 = (
  {
    props,
  },
) => <Text>Test</Text>;

const Component3 = ({ props }) => (
  <Text>
    Test
  </Text>
);

const Component4 = (
  {
    props,
  },
) => (
  <Text>
    Test
  </Text>
);

/* Why Component2, Component3, Component4 output from prettier are not the Component1 one ? */

See on Prettier website

So my final question, is why those 4 components that are absolutely the same, are turning into something different depending on how you originaly use Carriage Return ? Is this something you want ? or a bug ? because when i read in the Readme

It removes all original styling and ensures that all outputted JavaScript conforms to a consistent style.

It seems that it’s not consistent in this case 😃

Hope this is not something already discussed or an already existing bug (i search without founding any), if so, please apologize 😃

Thanks for helping

Kenny

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 5
Comments: 15 (9 by maintainers)

Commits related to this issue

Do not respect newlines for object destructuring pattern This was intended for object expressions. I tried to remove it for ObjectTypeAnnotation but it changes a ton of stuff as it's used all over th... — committed to vjeux/prettier by vjeux 7 years ago
Make single string jsx inline if possible Fixes part of #975 — committed to vjeux/prettier by vjeux 7 years ago
Do not respect newlines for object destructuring pattern (#981) This was intended for object expressions. I tried to remove it for ObjectTypeAnnotation but it changes a ton of stuff as it's used all ... — committed to prettier/prettier by vjeux 7 years ago

Most upvoted comments

At the beginning prettier started as pure formatter without looking at the original source. The first thing that broke down is empty lines. We haven’t found a good heuristic to put them in sensible places. We could get rid of them but they do add meaning to your code.

What is interesting is that if you do not give that control, people will go out of their way to get it back. Reason formatter doesn’t respect empty lines but add one before a comment. So people start putting useless comments just to get those empty lines.

We’ve tried to wait as much as possible before adding control. A lot of the issues that were coming next were about objects that were not properly expanded or shortened.

The problem with a project like prettier is that it reformats your entire codebase so if there is one thing that isn’t printed in an acceptable way, you are going to not use it at all. Object printing was such a thing for many people.

I think that in order for such a project to have a glimmer of a hope of succeeding we need to make trade-offs. Having objects and jsx respect the way it was inputted seems like a good one. It’s not fully consistent but at the same time, it doesn’t really hurt readability or understanding nor has the chance of leading to bugs.

vjeux on Mar 12, 2017

Awesome ! This is a huge win for consistency.

Thanks for keeping us updated and for the incredible work you made ! Everything from the communication (feedback, releases notes, issues, …) to the technical aspect are pure gold on Prettier 😃

kennydee on Jun 28, 2017

Probably worth writing up some of this, ideally with examples, in the readme somewhere… @kennydee 's question is a good one that a lot of users are likely to ask, and it’s worth explaining the nature of the tradeoffs at hand. Plus, it may help more people come up with better heuristics on how to break objects…

Though, of course, this issue has a pretty clear title and ask (thanks Kenny!) so hopefully curious folks can find it on google.

rattrayalex on Mar 12, 2017