
Prettier 2.0 – Opinionated JavaScript formatter - kristiandupont
https://prettier.io/blog/2020/03/21/2.0.0.html
======
Waterluvian
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 who are so deeply engaged in the product.

It means either all my code now needs a config file added or all my code will
need to be updated.

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

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

~~~
lonelappde
Configure your git blame to ignore cleanup changes.

[https://www.moxio.com/blog/43/ignoring-bulk-change-
commits-w...](https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-
git-blame)

~~~
Waterluvian
This changes everything. Thank you!!!

~~~
davidmurdoch
If GitHub doesn't automatically support the feature (article says it doesn't)
I don't think it'll be very useful for many teams.

~~~
capableweb
If you can use GitHub but not Git, I'm not sure you can really say that you
know version control. Fine for designers who are just helping out in projects
and don't really know to but developers who manages merges, backports and
alike should really know the insides of Git, not just the GitHub GUI.

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

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

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

------
simonw
I'm still really hoping for Jinja2/Django template support:
[https://github.com/prettier/prettier/issues/5754](https://github.com/prettier/prettier/issues/5754)
/
[https://github.com/prettier/prettier/issues/5581](https://github.com/prettier/prettier/issues/5581)

~~~
j-f1
This is actually quite challenging because the template language allows you to
insert template tags into any location in the template file, and while people
_usually_ put them in reasonable places, there’s no guarantee. For example,
someone could do a thing like `{{ less_than }}div class="foo">abc</div>` and
that would be totally valid but a nightmare to parse.

That’s different from a more structured template-style language like JSX,
where there are only a few valid places to embed JS expressions so it isn’t
too challenging to make them all look good.

------
dang
Related from 2018:
[https://news.ycombinator.com/item?id=16549966](https://news.ycombinator.com/item?id=16549966)

2017:
[https://news.ycombinator.com/item?id=14108718](https://news.ycombinator.com/item?id=14108718)

[https://news.ycombinator.com/item?id=13365470](https://news.ycombinator.com/item?id=13365470)

------
stared
Did they change an option to disable lineWidth? In 1.* it was not possible,
which was my single biggest issue with Prettier. Many times it made code less
coherent, due to forcing a few lines to be collapsed into one.

See Prettier example in ESLint section of "How I Learned to Stop Worrying and
Love the Types & Tests", [https://p.migdal.pl/2020/03/02/types-tests-
typescript.html#e...](https://p.migdal.pl/2020/03/02/types-tests-
typescript.html#eslint).

~~~
hombre_fatal
Why not just change it to a high value? Or prettier-ignore exceptional lines?

~~~
11235813213455
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, like how it'd force parenthesis in a `2
+ 3 * 4` expression, where it's a bit superfluous. Or string templates line
returns on expressions
[https://github.com/prettier/prettier/issues/3280](https://github.com/prettier/prettier/issues/3280)

~~~
Hurtak
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;

~~~
monkpit
But please don’t.

------
tony
In order to get this working with vim's prettier highlighting, I had to add
this to `.prettierrc`:

    
    
        {
          "trailingComma": "es5",
          "arrowParens": "always"
        }
    

Prettier 2.0 changed this to be the defaults, but for some reason the editor
plugin wasn't acknowledging it.

Also I added a script command to format all the code in package.json:

    
    
        {
          "scripts": {
            "prettier": "prettier src webpack data --write"
          }
        }
    

Then `npm run prettier` got me sync'd with the latest defaults (the
trailingComma and parens styling).

It even formatted my JSON and SCSS files. Didn't recognize prettier could do
that.

~~~
crooked-v
> but for some reason the editor plugin wasn't acknowledging it

Is it using a bundled pre-2.0 version of Prettier?

~~~
tony
Not sure, but it's this package: [https://github.com/prettier/vim-
prettier](https://github.com/prettier/vim-prettier)

------
ssutch3
I have been looking for, but haven't found, a similar package for Java
projects. Ideally my team can add it as a save-hook for everyone using IDEA,
then we can have a pre-commit hook that checks to ensure compliance. Would be
eternally grateful for anyone that can point me in the right direction!

~~~
dodobirdlord
I suggest [https://github.com/google/google-java-
format](https://github.com/google/google-java-format)

~~~
davnicwil
I'm very happy using this, coming from prettier with JS/VSCode and looking for
a similar dev experience in Java/Intellij - it has an IntelliJ plugin that
works well. Last time I looked I couldn't find any good IntelliJ plugins for
the Java implementation of prettier which was a dealbreaker - I need the
format on save. Anyway, this is a great tool, just works.

Only couple of issues it has is no 'ignore formatting for this piece of code'
feature and it occasionally formats comments oddly (i.e. enough to make them
unreadable) in certain edge cases like in ternary expressions, so you have to
manually edit comments from time to time, but this hardly ever comes up.

~~~
tomnipotent
> I need the format on save

Check out Preferences -> Tools -> File Watchers.

~~~
davnicwil
Great shout! Didn't know about this feature but this solves the problem
elegantly. Will give it a try.

------
berkayozturk
IMHO, when writing long logical expressions, putting the logical operators to
the beginning of each following line (instead of to the end) makes them much
easier to read.

------
msoad
finally you can run `npx prettier --write .` and get a folder formatted
without any installation or configuration. This is a great decision.
Congratulations on the release team!

~~~
mnutt
That's probably useful in some cases but I'd still recommend pinning the
version, since different versions of prettier format code differently and
different team members will end up with conflicting changes.

~~~
mceachen
^^^ what the op said. You'll regularly seen diffs in minor versions, and even
patch versions.

------
k__
Doesn't it defeat the idea of "one formatting to rule them all" if they change
the rules?

~~~
brlewis
I'm not sure how dedicated prettier is to "one formatting to rule them all"
since it's configurable per-project. Switching between different projects with
different prettier configuration is very low friction.

Speaking for myself, I advocate "one formatting to rule them all" in terms of
just taking defaults, and one of my arguments is that, if there's something
universally wrong about a prettier default, then it should be changed
universally. And if it isn't universally wrong, just go with the default.

~~~
k__
Yes.

Some things are obviously bugs, especially the chained line break problem.

Bur the semicolons config they added back in the days just baffled me.

------
jsthrowa
Friendly reminder that this will not necessarily build the same code from two
different sources with the same AST. For that, you can use:
[http://estools.github.io/escodegen/demo/index.html](http://estools.github.io/escodegen/demo/index.html)

------
ng12

      const identity = function (value) {
        return value;
      };
    

This change is really confusing to me. I've never seen anyone who puts a space
after the `function` keyword in an anonymous function.

~~~
capableweb
Not sure how much open source you've done, but StandardJS is used in a lot of
open source JS libraries/projects, and they have the "Add a space after
keywords" and "Add a space before a function declaration's parentheses" rules
in it, so plenty of open source projects does it like this.

------
iddan
Prettier is one of my favourite pieces of software! I only wish they had a
binary that doesn’t rely on Node.js

~~~
tln
Why?

Are you avoiding NPM as well?

Seems like a curious requirement for JS development

~~~
mattlondon
I avoid NPM if I can for JS development (after all not all JS/TS development
requires NodeJS) so it is painful to see people use npm as the installation
method for their projects or tools when I am trying to write something simple.

For what it is worth, the replacement for NodeJS (Deno) is removing the use of
npm, so I am not alone in my dislike of the centralised registry idea it
seems.

~~~
fictionfuture
Deno will fail at this, they are fixing something that isn't broken.

~~~
ss3000
IMHO, Deno's approach to package management, that is to say, no package
management ("packages" are just source files that you'd import directly using
urls or file paths), is a breath of fresh air compared to the status quo in
node where to import some javascript that's already hosted at some url (say on
github), you first have to "package" it by describing it with some manifest,
uploading it to some registry at a different url than the original, and then
"install" it using a package manager from that other url, and at the end of
the day not even have any guarantee that the content of that thing you
installed actually matches what you saw at the original url.

Deno's approach on the other hand is doesn't force any of that indirection
onto the user, and is analogous to (and compatible with) the model of modules
on the web. Package management systems can be easily layered on top of that if
the use case actually warrants that extra indirection, rather than having it
baked into the core of the runtime.

