10 ms·

Prettier 2.0 – Opinionated JavaScript formatter

207 points by kristiandupont 7y ago

dang 7y ago
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 7y ago
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#eslint https://p.migdal.pl/2020/03/02/types-tests-typescript.html#e....
- hombre_fatal 7y ago
  Why not just change it to a high value? Or prettier-ignore exceptional lines?
  - stared 7y ago
    Then it wraps longer statements into one line. Which for things of unrestricted length (e.g. arrays) is not an option.
  - 11235813213455 7y ago
    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
    - tomduncalf 7y ago
      I felt the same at first but I’ve honestly found after about a year of using prettier on every project that you just get used to the way it formats stuff and it’s a non-issue 99% of the time. Where it does do something awkward e.g. to long expressions with lots of operators in, usually it’s actually a sign that you can make it clearer by splitting it into multiple smaller expressions which helps overall readability. I think you can also tell prettier to ignore certain lines, though I don’t think I’ve ever needed to.
    - Hurtak 7y ago
      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 7y ago
        But please don’t.
- j-f1 7y ago
  This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit. We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.
- jchook 7y ago
  I’ve learned that the benefit of Prettier outweighs its cost in this regard. At first I disliked things about Prettier. For example, indents violate eslint’s “indent” rule with multiline ternary alignment. However, I just turned off those eslint rules and stopped worrying about it b/c Prettier’s format is “good enough” and saves me a ton of keystrokes.
msoad 7y ago
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 7y ago
  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 7y ago
    ^^^ what the op said. You'll regularly seen diffs in minor versions, and even patch versions.
- thorn0x 7y ago
  npx is fine, just remember not to use it for things like CI without pinning the version of Prettier (`npx prettier@2.0.1 ...`).
iddan 7y ago
Prettier is one of my favourite pieces of software! I only wish they had a binary that doesn’t rely on Node.js
- tln 7y ago
  Why? Are you avoiding NPM as well? Seems like a curious requirement for JS development
  - minieggs 7y ago
    Yes. I would prefer the only JavaScript VM on my computer to be the browser's. Aside: I wouldn't sell what I do as JavaScript development, though.
    - z3t4 7y ago
      For the last 25 years, many apps have come with their own JS engine for scripting abilities. Ms Office, Photoshop, et. al. Not just the web browser. And more and more "native" apps have a built in JS engine. And then there's apps that not only have a JS engine, but a whole browser (Electron, Nw.js). So it would be difficult to purge your system from anything that can run JS :P
  - mattlondon 7y ago
    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 7y ago
      Deno will fail at this, they are fixing something that isn't broken.
ssutch3 7y ago
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!
- ljm 7y ago
  I've been using Spotless, which has been working well enough.
- dodobirdlord 7y ago
  I suggest https://github.com/google/google-java-format https://github.com/google/google-java-format
  - davnicwil 7y ago
    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 7y ago
      > I need the format on save Check out Preferences -> Tools -> File Watchers.
      - davnicwil 7y ago
        Great shout! Didn't know about this feature but this solves the problem elegantly. Will give it a try.
k__ 7y ago
Doesn't it defeat the idea of "one formatting to rule them all" if they change the rules?
- mirekrusin 7y ago
  The king is dead, long live the king!
- gherkinnn 7y ago
  It will be difficult to find adoption if you can’t make room for options like removing unnecessary semicolons.
- brlewis 7y ago
  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__ 7y ago
    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.
- tlrobinson 7y ago
  I don't think Prettier ever claimed to be the one true formatting everyone must use for it to be successful. It's a tool that formats code nicer then most other tools. Personally, I would rather a project use a formatting tool that outputs a format I don't like than not using a formatting tool at all. I just don't want to have to waste mental bandwidth on formatting ever again.
  - k__ 7y ago
tony 7y ago
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 7y ago
  > but for some reason the editor plugin wasn't acknowledging it Is it using a bundled pre-2.0 version of Prettier?
  - tony 7y ago
    Not sure, but it's this package: https://github.com/prettier/vim-prettier https://github.com/prettier/vim-prettier
Waterluvian 7y ago
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 7y ago
  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 7y ago
    Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.
    - Waterluvian 7y ago
      This used to have no value to me. But years into my career I discovered that I can't live without it. Detective work on the history of code is vital to truly groking why things are the way they are in code bases.
    - Groxx 7y ago
      --ignore-rev: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w... Personally tho I haven't had an issue navigating back another revision. UIs are good at handling that kind of interaction, and I rarely use blame without a UI. (nearly every other git interaction: CLI all the time. but not blame.)
franciscop 7y ago
> 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.
- hombre_fatal 7y ago
  You should peg dev-deps just like any other dep.
  - franciscop 7y ago
    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.
    - hombre_fatal 7y ago
      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. :)
- traviswt 7y ago
  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.
simonw 7y ago
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
- gkoberger 7y ago
  Prettier was originally created by James Long, who also created Nunchucks (which is the Node port of Jinja2, since we were all familiar with Jinja2 at Mozilla). I don't really have a point since he's not involved in either anymore; just thought it was interesting!
- j-f1 7y ago
  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.
jsthrowa 7y ago
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
berkayozturk 7y ago
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.
ng12 7y ago
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 7y ago
  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.

dang 7y ago

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 7y ago

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#eslint https://p.migdal.pl/2020/03/02/types-tests-typescript.html#e....

hombre_fatal 7y ago
Why not just change it to a high value? Or prettier-ignore exceptional lines?
- stared 7y ago
  Then it wraps longer statements into one line. Which for things of unrestricted length (e.g. arrays) is not an option.
- 11235813213455 7y ago
  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
  - tomduncalf 7y ago
    I felt the same at first but I’ve honestly found after about a year of using prettier on every project that you just get used to the way it formats stuff and it’s a non-issue 99% of the time. Where it does do something awkward e.g. to long expressions with lots of operators in, usually it’s actually a sign that you can make it clearer by splitting it into multiple smaller expressions which helps overall readability. I think you can also tell prettier to ignore certain lines, though I don’t think I’ve ever needed to.
  - Hurtak 7y ago
    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 7y ago
      But please don’t.
j-f1 7y ago
This isn’t really possible due to Prettier’s design, unfortunately. It basically lays out each statement on one line until it gets to the maximum width, then tries a variety of ways to break the line until it’s under the limit. We also don’t want to look at how the code is formatted coming in because one of Prettier’s goals is to make sure everyone’s code looks the same, which wouldn’t be possible if we looked at how the input is formatted too much.
jchook 7y ago
I’ve learned that the benefit of Prettier outweighs its cost in this regard. At first I disliked things about Prettier. For example, indents violate eslint’s “indent” rule with multiline ternary alignment. However, I just turned off those eslint rules and stopped worrying about it b/c Prettier’s format is “good enough” and saves me a ton of keystrokes.

msoad 7y ago

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 7y ago
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 7y ago
  ^^^ what the op said. You'll regularly seen diffs in minor versions, and even patch versions.
thorn0x 7y ago
npx is fine, just remember not to use it for things like CI without pinning the version of Prettier (`npx prettier@2.0.1 ...`).

iddan 7y ago

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

tln 7y ago
Why? Are you avoiding NPM as well? Seems like a curious requirement for JS development
- minieggs 7y ago
  Yes. I would prefer the only JavaScript VM on my computer to be the browser's. Aside: I wouldn't sell what I do as JavaScript development, though.
  - z3t4 7y ago
    For the last 25 years, many apps have come with their own JS engine for scripting abilities. Ms Office, Photoshop, et. al. Not just the web browser. And more and more "native" apps have a built in JS engine. And then there's apps that not only have a JS engine, but a whole browser (Electron, Nw.js). So it would be difficult to purge your system from anything that can run JS :P
- mattlondon 7y ago
  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 7y ago
    Deno will fail at this, they are fixing something that isn't broken.

ssutch3 7y ago

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!

ljm 7y ago
I've been using Spotless, which has been working well enough.
dodobirdlord 7y ago
I suggest https://github.com/google/google-java-format https://github.com/google/google-java-format
- davnicwil 7y ago
  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 7y ago
    > I need the format on save Check out Preferences -> Tools -> File Watchers.
    - davnicwil 7y ago
      Great shout! Didn't know about this feature but this solves the problem elegantly. Will give it a try.

k__ 7y ago

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

mirekrusin 7y ago
The king is dead, long live the king!
gherkinnn 7y ago
It will be difficult to find adoption if you can’t make room for options like removing unnecessary semicolons.
brlewis 7y ago
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__ 7y ago
  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.
tlrobinson 7y ago
I don't think Prettier ever claimed to be the one true formatting everyone must use for it to be successful. It's a tool that formats code nicer then most other tools. Personally, I would rather a project use a formatting tool that outputs a format I don't like than not using a formatting tool at all. I just don't want to have to waste mental bandwidth on formatting ever again.
- k__ 7y ago

tony 7y ago

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 7y ago
> but for some reason the editor plugin wasn't acknowledging it Is it using a bundled pre-2.0 version of Prettier?
- tony 7y ago
  Not sure, but it's this package: https://github.com/prettier/vim-prettier https://github.com/prettier/vim-prettier

Waterluvian 7y ago

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 7y ago
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 7y ago
  Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.
  - Waterluvian 7y ago
    This used to have no value to me. But years into my career I discovered that I can't live without it. Detective work on the history of code is vital to truly groking why things are the way they are in code bases.
  - Groxx 7y ago
    --ignore-rev: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w... Personally tho I haven't had an issue navigating back another revision. UIs are good at handling that kind of interaction, and I rarely use blame without a UI. (nearly every other git interaction: CLI all the time. but not blame.)

franciscop 7y ago

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

hombre_fatal 7y ago
You should peg dev-deps just like any other dep.
- franciscop 7y ago
  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.
  - hombre_fatal 7y ago
    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. :)
traviswt 7y ago
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.

simonw 7y ago

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

gkoberger 7y ago
Prettier was originally created by James Long, who also created Nunchucks (which is the Node port of Jinja2, since we were all familiar with Jinja2 at Mozilla). I don't really have a point since he's not involved in either anymore; just thought it was interesting!
j-f1 7y ago
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.

jsthrowa 7y ago

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

berkayozturk 7y ago

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.

ng12 7y ago

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