
Prettier 1.0 - vjeux
http://jlongster.com/prettier-1.0
======
rattray
Prettier is a code formatter for JavaScript, like the hugely popular "gofmt".

Highlights of the 1.0 announcement:

\- production-ready (and used, eg; React, Oculus, Cloudflare, etc)

\- --no-semi option

\- --use-tabs option

\- parens that help indicate precedence

\- many formatting improvements

There are a ton of edge cases in this work that really matter (read through
the announcement for a few). Speaking as a contributor, this is some of the
hardest stuff I've ever done (beats building a JS superset,
[http://lightscript.org](http://lightscript.org)). I've been super impressed
by the prettier team.

~~~
bradfitz
We had configurability in early versions of gofmt but realized it was a
mistake and kinda missed the whole point of having a code formatter, so we
removed them.

~~~
mrkgnao
While I understand the reasons for this (especially with the culture, for lack
of a better word, around Go), I feel like this is a step backward in general.
The "standard" Haskell formatter, hindent, did something similar. I found the
maintainer's behavior admirable -- the style that was agreed on was very
different from his own, but it was what he saw after analyzing publicly
available code -- but what's the problem with custom formats if they're
consistent across a whole codebase?

~~~
jaredklewis
What's the advantage of project specific, custom formats?

~~~
gknoy
It allows everyone in your company's dev organization share a common
`standard` of JS style, which you have agreed on, even if it differs slightly
in the way it bikesheds things like single-vs-double quotes or the presence of
semicolons. (I mention `standard` because we use it as the basis for our
linting rules, and would LOVE to use prettier to reformat our code.)

------
sgslo
Prettier goes such a long way to enforcing standards on a language and
ecosystem which otherwise has none or few. What standards do exist are
frequently arbitrary, or enforced by legacy code at random companies. For
example, the Airbnb JS style guide [1] recommends single quotes in JS, but
double quotes for JSX properties. Why the difference? Why not stick with
double quotes everywhere, as they are required in JSX blocks? Answer: legacy
code at Airbnb [2]

I'm hoping to see similar efforts on project file/folder structure at some
point. How often do two node projects created by different engineering teams
end up with the same folder/file structure? There's nearly no strong community
convention, unlike many other languages/frameworks. Rails, for example,
famously touts that any engineer can walk onto another Rails project and have
a reasonable suspicion of where to find a particular piece of code.

1:
[https://github.com/airbnb/javascript](https://github.com/airbnb/javascript)
2:
[https://twitter.com/hshoff/status/784205839347232768](https://twitter.com/hshoff/status/784205839347232768)

~~~
_harry
One of the Airbnb style guide authors here.

The point about quotes comes up often. The important part for us is
consistency at Airbnb. We use eslint to enforce and maintain the consistency.
Would it be more consistent to treat strings the same everywhere? For some
projects sure. We diverge from the community a bit in the sense that we treat
JSX as not JS and we aim to be consistent about that. If your project treats
JSX and JS the same then yes, we've certainly seen folks do this. As always,
please do what works best for your team or project [1]. Forks encouraged.

I will say an added benefit of including a style guide in a project for large
teams that may get lost jumping straight into prettier, has been helping our
engineers become stronger javascript programmers in the process of learning
our style guide. That's largely anecdotal evidence from my time at Airbnb and
of course your mileage my vary.

Personally, I support the Prettier mission 100%. Easier consistency is huge.
Removing barriers to contributing to open source projects is huge. PR reviews
focused on what the code is doing vs painful style nits is huge. It's been
great to see this come from the community and I look forward to seeing where
the community takes it. Congrats to all of the contributors on the 1.0!

[1]
[https://github.com/airbnb/javascript/issues/102](https://github.com/airbnb/javascript/issues/102)

~~~
austincheney
Pretty Diff contains an option to convert string quotes to either double
quotes or single quotes. This was a trivial update and I would be amazed if
its absent in other beautifiers.

~~~
rattray
Yes, prettier has a `--single-quote` option (default false).

------
startupdiscuss
The amazing thing, for me, is:

1\. Announced 2 months ago

2\. Already adopted by, it seems, every major JS project.
([https://twitter.com/jlongster/status/852532847252566017](https://twitter.com/jlongster/status/852532847252566017))

3\. 7000 stars, 100,000 npm downloads/mo

Now some people will say it is a better mousetrap, but even now I can't tell
you what the difference is between it and all the other linters. I can tell
you that, based on the popularity, I would just default to this one and assume
all this famous projects and people have worked it out.

How did it get it so popular? What made people want to try it out? Just word
of mouth?

~~~
dguo
Speaking for myself, I've been waiting for 1.0 before using it, but I've been
very excited for this project since its announcement. I've personally
experienced how much time can be wasted bikeshedding over stylistic issues. In
most cases, just picking a consistent standard is far more important than
whatever the choice happens to be. Prettier will make almost all that
bikeshedding unnecessary.

Even with ESLint having autofix capabilities, Prettier seems far more
comprehensive in that regard. It also isn't doing exactly the same things as
linters. They check for programming errors as well, not just stylistic issues.
With those linters, you also need to decide how to configure the rules (though
picking a preset can make that easier).

I have always loved that Python has an "official" style guide
([https://www.python.org/dev/peps/pep-0008/](https://www.python.org/dev/peps/pep-0008/)),
and gofmt ([https://golang.org/cmd/gofmt/](https://golang.org/cmd/gofmt/)) is
one of the reasons I want to try out Go, so Prettier is a great development in
my opinion. I am optimistic that the community will keep on adopting it,
helping make our code more readable and allowing us to focus on actually
building libraries, tools, applications, etc. rather than arguing over where
we should and shouldn't have spaces in our code.

Edit: my TL;DR answer would be that it's a virtually zero configuration way to
guarantee stylistic consistency.

------
jbrantly
Really looking forward to TypeScript support [0] as that's blocking me from
using this in most of my work-related projects. Congrats to the team on 1.0!

0:
[https://github.com/prettier/prettier/issues/13](https://github.com/prettier/prettier/issues/13)

~~~
pfooti
Yeah, that's what I thought when I saw this project for the first time today.
And here I just started moving everything to typescript.

------
vmasto
I recall the React team were discussing at what part of the build step they
should include Prettier.

I believe there was an idea of adding it as a pre-commit hook, a second one as
a manual step and another one as a post-commit amend.

Have we reached a consensus on that? Not up to date what they went with, what
seems to be the best way to do this?

~~~
danabramov
We currently do the same thing Jest does: no hooks, but we offer it as `npm
run prettier`, and we also run the comparison on CI (so if the prettier output
is different, the PR fails). This means the code is always checked in
formatted, but people need to remember to run `npm run prettier` or CI will
fail.

~~~
vmasto
Interesting, thanks Dan.

------
MisterKent
This is getting closer to my dream setup of being able to open files in my
formatting, and saving them in the team's formatting.

Formatting source code feels like a complete waste of developer time and
energy, especially when they don't agree with how the team has decided to
format the code. I almost wish source code files could be just serialized ASTs
and that a VCS could understand them making merges etc. even easier.

~~~
tyingq
I'm surprised that doesn't exist. When I did a lot of Perl in a team
environment, we used perltidy. Helpful since Perl does little to encourage
uniformity.

It could take any sort of style in, and produce any sort of style out. Things
like K&R blocks vs Allman-style blocks, tabs vs spaces, line wrapping,
cuddled/not-cuddled else, etc.

[http://perltidy.sourceforge.net/stylekey.html](http://perltidy.sourceforge.net/stylekey.html)

Edit: this looks pretty close to the same thing for JavaScript. Missing some
style options, and not command line driven, but the general idea seems close:
[https://github.com/benjamn/recast/blob/master/README.md](https://github.com/benjamn/recast/blob/master/README.md)

------
krick
People here seem to approve it, but I feel unsure. Example with the matrix
shows pretty well, why exceptions are always possible, no matter how detailed
your styleguide is. And using comments to hold your auto-formatter back always
baffles me. It seems so misaligned with the original purpose of writing the
code (which comments are a part of).

It might be useful to re-format a completely messed up piece of code coming
from the external world, but on the team I always prefer styleguides in the
mood of "recommended, never enforced", which "prettier" is exact opposite of.
That is, try to write like everyone else on the team does, but avoid re-
formatting the code written by someone else, if there's no real need to do so.
Obvious, strictly formal things like spaces instead of tabs, spaces outside of
brackets (not inside of them), etc — this is one thing. But aligning pieces
code to match some meta-pattern, or using longer/shorter lines than usual for
some specific, "artistic" purpose — come on, this is not such a big deal.
Consistency is overrated.

------
marcrosoft
I feel like you have to give Go credit for exposing this type of productivity
hack. Once you gofmt/goimports on save you will never go back.

Edit: If I had to program in JS I would definitely use this coming from Go.

~~~
rattray
gofmt helped drive the demand and popularity for prettier, but people have
been trying to build something like it for JS since before Go existed [0].

Prettier has succeeded largely due to a better algorithm, which actually came
from the haskell community, via Wadler's paper A Prettier Printer [1] (with an
implementation available at [2]).

[0] js-beautify had its first commit in 2007: [https://github.com/beautify-
web/js-beautify/commit/e1ddc28b2...](https://github.com/beautify-web/js-
beautify/commit/e1ddc28b2ac8140047269562e375f018c58e3a7e)

[1]
[https://homepages.inf.ed.ac.uk/wadler/papers/prettier/pretti...](https://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf)
[PDF]

[2] [https://hackage.haskell.org/package/wl-
pprint](https://hackage.haskell.org/package/wl-pprint)

------
antirez
I'll never understand code formatters. For me the idea of my code passing
through a formatter, is like if accidentally I lost part of it: there is a lot
of care in the way you write your code, even in the part that the compiler
does not care about: spaces. Spaces are the rhythm of the code... not sure why
one would write code without rhythm and later add a synthetic one.

~~~
jlongster
You might be surprised at the quality of the output (obviously I'm biased).
We've tried to choose what most people consider to be the best way to style
code, and many times prettier ends up formatting complex code better than I
would have manually. Also, the biggest benefit that a lot of people don't
realize is it allows you to quickly restructure your code easily:
[http://jlongster.com/s/refactor.gif](http://jlongster.com/s/refactor.gif)

I understand if the way prettier formats your code is not the way you would
like, and is more of a hindrance than helpful. But I hope the above gif shows
why it is freeing for a lot of people.

Also, note that prettier does keep the original blank lines in your code.
That's where most of the rhythm comes from, and we allows authors to group
code however they want. The rest of it is basically choosing whether to insert
a space here or there or not.

I respect your work, antirez, and I hope you at least try it once! It's
totally fine if it's not useful for you though.

~~~
antirez
Hello! Don't get me wrong, I'm not saying that code formatters are not useful,
they are _massively_ useful in order to turn badly formatted code into more
readable code, and also when there is to integrate some code from a code base
to another and needs to be re-formatted and so forth. What I find odd is that
there are people using it as a "to go" solution for code indentation. The fact
btw that it keeps the original blank lines is a great feature that saves a lot
of semantics. Thanks for your comment!

------
ggregoire
I was waiting the --no-semi option to start using Prettier. Thanks to the
team!

~~~
dkn
The option seems to put semicolons at the front of your code instead of at the
end. Am I wrong? Why is this attractive?

~~~
exogen
They specifically demonstrated a case where that's necessary [1], it doesn't
always do that.

[1]
[https://github.com/feross/standard/blob/master/RULES.md#semi...](https://github.com/feross/standard/blob/master/RULES.md#semicolons)

------
ChicagoBoy11
I can't overstate how freeing coding with prettier has been -- often I'd find
myself quickly grokking something and once I finally got it to "work," make
sure it was all styled properly. Since using prettier, these things are one-
and-the-same, which is a tremendous gain.

~~~
imjared
Something that's kind of tricky for me and my team is that we disagree on
things like indentation and spacing in/around brackets and parens. The
disagreement isn't just a "I think it should be done this way..." but "I
actually understand code better when it's written this way..."

If we were to implement prettier, and chose to use 2-space indents, for a
simple example, how would a 4-space developer fare when they pulled down the
Prettified code? Would they just set up their own config locally based on
their own standards?

~~~
rattray
That doesn't sound like a good idea (after all, there can only be one codebase
in source control) but I believe it actually would be possible – and in fact,
prettier would be a vital component to making it happen.

If you have a pair of particularly persnickety peers, you could theoretically:

1) run prettier with the company-wide config as a precommit hook
([https://github.com/prettier/prettier#pre-commit-hook-for-
cha...](https://github.com/prettier/prettier#pre-commit-hook-for-changed-
files))

2) instruct your colleagues to have their editor run prettier with their own
preferences on save.

This way, your colleagues can simply open a file locally and save it to see
things their way – and the code will be back to company-normal when they
commit. They'll still have to see that unbearable bracket-spacing during code
review, of course.

Prettier doesn't have many configuration options (intentionally!) so they'd
probably opt to use prettier-eslint or similar, which allows more
configuration (at the cost of speed).

Hopefully, after trying this, they would come to the conclusion that life is
better just using the defaults, two-space-indents be damned. Bikesheds are
great places for compromise.

------
bcherny
How does Prettier compare to
[https://github.com/millermedeiros/esformatter](https://github.com/millermedeiros/esformatter),
[https://github.com/beautify-web/js-beautify](https://github.com/beautify-
web/js-beautify),
[https://github.com/jedmao/codepainter](https://github.com/jedmao/codepainter),
[https://github.com/rdio/jsfmt](https://github.com/rdio/jsfmt), etc.?

Personally, I use TSLint with the tslint.autoFixOnSave VSCode setting, and
couldn't be happier.

~~~
sotojuan
[https://news.ycombinator.com/item?id=14110204](https://news.ycombinator.com/item?id=14110204)

------
wildpeaks
It would be useful to compare with "eslint --fix" given Eslint can already
reformat (on top of linting non-style things, and projects usually already
have Eslint settings).

~~~
rattray
From the readme:

Unlike ESLint ... __everything is fixable __. This works because Prettier
never "checks" anything; it ... parses your JavaScript into an AST (Abstract
Syntax Tree) and pretty-prints the AST, completely ignoring any of the
original formatting.

There's an extremely important piece missing from existing styling tools: the
maximum line length ... (ESLint never knows how to fix it).

[https://github.com/prettier/prettier](https://github.com/prettier/prettier)

------
jacobr
What's the best way to add this to an existing project?

Going through all code at once would destroy all relevant vcs history and git
blame. Maybe before each substantial edit on a file first run it through
prettier and then make your real changes in a separate commit?

~~~
josephfrazier
You can have git diff/blame/etc ignore stylistic changes by configuring
prettier as a textconv [1]. I'm building a `git diff` wrapper that does this
for you [2].

[1]:
[https://git.wiki.kernel.org/index.php/Textconv](https://git.wiki.kernel.org/index.php/Textconv)

[2]: [https://github.com/josephfrazier/prettier-
diff](https://github.com/josephfrazier/prettier-diff)

------
pomber
One of those tools that you don't realize how much you need it until you use
it.

------
crucialfelix
I love this thing, have it on auto save. It saves so much time. Now I can
write remove a nesting, leave dangling commas and I don't have to even waste a
second to clean it up. Just hit save and everything slips into place.

------
k__
Prettier is like rainbow sprinkels on top of my code.

I write vastly different JS as Prettier formats (single quotes, no semicolons,
etc.), but after I hit save everything just looks 'normalised'

------
gyrgtyn
I really like it for personal stuff.

I'd like to hear how people are using it on teams. With some effort I got it
working on save in emacs, but asking other people to please install more
tooling is not always easy.

I do have some authority over package.json though. How would you make it just
work for everyone (using atom, vim, etc...)

~~~
rattray
One option is to add prettier as a precommit hook, eg;
[https://github.com/prettier/prettier#pre-commit-hook-for-
cha...](https://github.com/prettier/prettier#pre-commit-hook-for-changed-
files) which doesn't require editor integrations at all.

There are integrations for most editors (Atoms, Emacs, Vim, Neovim, VSCode,
VS, Sublime Text, JetBrains):

[https://github.com/prettier/prettier#editor-
integration](https://github.com/prettier/prettier#editor-integration)

------
sergiotapia
How can I use this on file save within Atom?

Edit: Oh here we go: [https://github.com/prettier/prettier-
atom](https://github.com/prettier/prettier-atom)

------
pfzero
How is prettier compared to vscode autoformat feature?

------
ArlenBales
What is the Prettier equivalent for SCSS and HTML?

~~~
dkn
I don't know that there is one. From the repository README:

> Prettier bans all custom styling by parsing it away and re-printing the
> parsed AST with its own rules that take the maximum line width into account,
> wrapping code when necessary.

------
hellofunk
Is this basically clang-format for JS?

