Live data from Hacker News

Prettier 2.0 – Opinionated JavaScript formatter

prettier.io

61–70 of 91 posts

Re: Prettier 2.0 – Opinionated JavaScript formatter

#61
post #60

I'm still really hoping for Jinja2/Django template support: https://github.com/prettier/prettier/issues/5754 / https://github.com/prettier/prettier/issues/5581

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!

Re: Prettier 2.0 – Opinionated JavaScript formatter

#62
post #60

I'm still really hoping for Jinja2/Django template support: https://github.com/prettier/prettier/issues/5754 / https://github.com/prettier/prettier/issues/5581

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#63

> 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 someth…

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#64

Earlier quoted context omitted.

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

This changes everything. Thank you!!!

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#65
post #50

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…

> Before version 2.0, Prettier was avoiding trailing commas by default where possible. This made the resulting JavaScript compatible with now very old environments such as IE8, but implied some missed opportunities. Seems like a pretty good reason to change that one at least, since it seems to imply they've wanted trailing commas but didn't do it for compatibility reasons.

I find trailing commas annoying because every once in a while I need to copy some object to use as JSON and... it doesn't work since JSON doesn't support trailing commas.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#66

Earlier quoted context omitted.

Run it in Docker. https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...

Whoah, aliasing shell commands to Docker one-offs for ethereal runs. Super useful, never thought of that. This comment was a hidden gem in this thread, I've bookmarked that blog post.

Thanks, that's kind of you to say. Running things like this in Docker is a very handy pattern.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#67

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…

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.

It will likely conflict most in-progress PR. For PRs that are large and long lived it will be a PITA to maintain and will further slow integration so, likely, yes.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#68

Earlier quoted context omitted.

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.

We had to change the old default because of TypeScript complaining if the param has a type annotation and no parens. So it's more consistent with TypeScript now as well. I had to argue for this exception to be added to our config, so it's a nice bit of validation that Prettier has come around.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#69

> 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 someth…

Well, there is

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

Re: Prettier 2.0 – Opinionated JavaScript formatter

#70
post #50

Earlier quoted context omitted.

> Before version 2.0, Prettier was avoiding trailing commas by default where possible. This made the resulting JavaScript compatible with now very old environments such as IE8, but implied some missed opportunities. Seems like a pretty good reason to change that one at least, since it seems to imply they've wanted trailing commas but didn't do it for compatibility reasons.

I find trailing commas annoying because every once in a while I need to copy some object to use as JSON and... it doesn't work since JSON doesn't support trailing commas.

Why the down vote? Prettier calls itself "an opinionated JavaScript formatter". It _had_ an opinion that I agreed with, and now it doesn't. I just offered a perspective on why I don't agree.
Post reply on HN