Hacker News Reader

Comment by franciscop | Hacker News Reader

> 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.

View on HN

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.

You've perfectly explained my daily frustration with Prettier. I am sad a few times a day about this for a project I'm on at this time.

Well, there is

  //prettier-ignore

https://prettier.io/docs/en/ignore.html#javascript

I personally really enjoy the automatic line breaking behavior of prettier as it frees me from having to make this entire class of purely stylistic decisions but still have code formatted in a reasonably legible manner.

But I also have wished on multiple occasions that prettier was just an opinionated preset on top of a much more configurable core, which would make it less of a taboo to add options for what are obviously massively divisive formatting preferences.

Case in point, all the most popular issues in the repo are some form of people asking for options or changes to the current behavior: https://github.com/prettier/prettier/issues?q=is%3Aissue+is%...

And let's face it, that whole idea of a 1-size-fits all JS code formatting tool to end all formatting debates? That ship has sailed a long time ago. The debate just moved to what prettier options to use: https://prettier.io/docs/en/options.html

I think the real value of prettier these days is that we can debate as a team once, decide on an option, and then have that decision be enforced automatically moving forward. A configurable core + opinionated defaults can serve that use case just as well.

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

I prefer not to add an extra step for newbies devs contributing to my open source projects. So if someone makes a PR and it's not well formatted, not a big deal.

For work, sure agree.

They don't need to apply prettier, but it does no harm that it's sitting in their node_modules pegged to the version you're using.

Also, you may be underestimating beginners. If someone can learn git, how to make a substantial code contribution, and lift it into a PR, they can run your `npm run prettier` step. :)

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.

Reply on news.ycombinator.com