Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prettier 2.0 – Opinionated JavaScript formatter

prettier.io

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Prettier 2.0 – Opinionated JavaScript formatter

#51

Post by monkpit »

Hurtak wrote: post #41
11235813213455 wrote: post #10

Earlier quoted context omitted.

if you put a high lineWidth value, you'll have your object literals or destructuring mostly one-lined, etc.. often not desirable (for 4+ props) That's mostly why I don't like prettier, sometimes you want a bit of control over code formatting when several options are possible, prettier don't allow it. I use vscode formatter (actually it's TypeScript compiler formatter) instead Other things I dislike with prettier, lik…

You can controll the formatting with empty comments eg, if you dont like const {a, b, c} = props; you can do const { // a, b, c } = props;

But please don’t.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#52

Post by akiselev »

afshin wrote: post #42
greentrust wrote: post #31

Earlier quoted context omitted.

Is the cost really that high? For the vast majority of projects, all developers will need to do is run "yarn prettier". We can't expect everything to be perfect on day one, nor should we be stuck with the poor choices we made when starting a project. Maintainers should be allowed to change their mind after careful consideration and community consensus.

Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.

The loss is a bit of convenient tooling but it can be replaced with some slightly less convenient tooling. It's not going to be an architectural limitation and you can treat it as a relatively simple per company/team/project tradeoff.

Especially when working with syntax heavy compiled languages like Rust, autoformat on save frees me up enough mental capacity for me that the costs are well worth it for the extra development speed. I just use Git Lens and some custom git aliases to get around the messy logs, whereas my last team handled the payment frontend for a large company so tracing the history of changes was taken way more seriously and reformatting someone else's code outside of organized refactorings, let alone autoformat, was disqualified from the start.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#53

Post by franciscop »

> Improved method chain breaking heuristic

This is great! When I'm scripting in Node.js I tend to prefer either of these two styles, with the second one being normally a cleaned-up version of the first one:

    const res = base
      .map(a => a.b)
      .filter(b => /abc/.test(b))
      .join('\n');

    const res = base.map(extractB).filter(isAbc).join('\n');
The second one would be split into different lines with Prettier 1.x, which was annoying since I would explicitly extract those methods into separated functions for clarity. So this is amazing for my personal projects.

However at the same time I'm not thrilled about prettier breaking changes. It is supposed to be the one way of doing things, so now a project might have different people with different prettier versions, making it a ping-pong game if someone has prettier 1 and someone else prettier 2.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#54

Post by mpawelski »

gkoberger wrote: post #39
Waterluvian wrote: post #29

A bit irritating that formatting zealots are changing the defaults. What can possibly drive the decision to change whatever option it is they landed on and deployed? It's contrary to everything they claimed Prettier was about: for better or worse, we have decided on X so we can all move on to more important issues. I feel like the cost of changing defaults is wildly underestimated because it's decided on by people wh…

I'm not sure how you can say these are zealots making these changes? The three defaults things they changed all seemed incredibly sane, and were made for really good reasons. I think there's another way to look at it. It's more "we have decided on X so YOU can move on to more important issues." With Prettier, you just follow their opinions. Their opinions can change, and your code might look different, but it doesn't…

I wouldn't call change of `arrowParens` to `always` as "incredibly sane". This is just a differt opinion about what is "better". I have different.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#55

Post by hombre_fatal »

franciscop wrote: post #53

> Improved method chain breaking heuristic This is great! When I'm scripting in Node.js I tend to prefer either of these two styles, with the second one being normally a cleaned-up version of the first one: const res = base .map(a => a.b) .filter(b => /abc/.test(b)) .join('\n'); const res = base.map(extractB).filter(isAbc).join('\n'); The second one would be split into different lines with Prettier 1.x, which was ann…

You should peg dev-deps just like any other dep.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#56

Post by gkoberger »

mpawelski wrote: post #54
gkoberger wrote: post #39

Earlier quoted context omitted.

I'm not sure how you can say these are zealots making these changes? The three defaults things they changed all seemed incredibly sane, and were made for really good reasons. I think there's another way to look at it. It's more "we have decided on X so YOU can move on to more important issues." With Prettier, you just follow their opinions. Their opinions can change, and your code might look different, but it doesn't…

I wouldn't call change of `arrowParens` to `always` as "incredibly sane". This is just a differt opinion about what is "better". I have different.

I like it, because it's consistent. If you remove or add a parameter to a function, you have parenthesis either way and don't have to think about it.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#57

Post by traviswt »

franciscop wrote: post #53

> Improved method chain breaking heuristic This is great! When I'm scripting in Node.js I tend to prefer either of these two styles, with the second one being normally a cleaned-up version of the first one: const res = base .map(a => a.b) .filter(b => /abc/.test(b)) .join('\n'); const res = base.map(extractB).filter(isAbc).join('\n'); The second one would be split into different lines with Prettier 1.x, which was ann…

I have a pre-commit hook configured to format staged changes. It uses husky and pretty-quick. With this approach, you should get standard commits, even if the user’s installed tooling differs.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#58

Post by atombender »

franciscop wrote: post #53

> Improved method chain breaking heuristic This is great! When I'm scripting in Node.js I tend to prefer either of these two styles, with the second one being normally a cleaned-up version of the first one: const res = base .map(a => a.b) .filter(b => /abc/.test(b)) .join('\n'); const res = base.map(extractB).filter(isAbc).join('\n'); The second one would be split into different lines with Prettier 1.x, which was ann…

I prefer Gofmt's strategy/philosophy, which is to mostly let the developer control breaking, and only format around it. Gofmt will format everthing strictly, but will leave decisions about "layout" to you.

This is a wiser design because the formatter can't know what the best layout is, and a formatter really ought to only format something where there's is an unequivocally, universally correct way of formatting something.

As an example, sometimes table-driven test are better written compactly, sometimes better verbosely. As a naive example:

  for _, c := range []testcase{
    {input: 1, expect: 10},
    {input: 2, expect: 20},
    {input: 3, expect: 30},
  } {
    assert.Equal(t, c.expect, someFuncToBeTested(c.input))
  }
If the formatter starts splitting each testcase entry up over several lines, like so:

    {
      input: 1,
      expect: 10,
    },
...then you potentially lose readability. In other cases, you have more complicated structs that might fit on one line, but deserve to be formatted across multiple lines.

This is something Prettier doesn't always do correctly, and with Prettier, you don't have a choice. Opinionated is good when there is just one answer, but not when there's a range of possibly answers.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#59

Post by Waterluvian »

lonelappde wrote: post #49
afshin wrote: post #42

Earlier quoted context omitted.

Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.

Configure your git blame to ignore cleanup changes. https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

This changes everything. Thank you!!!
Post reply on HN