Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prettier 2.0 – Opinionated JavaScript formatter

prettier.io

Post reply on HN
Print view View original

81–90 of 91 posts

Re: Prettier 2.0 – Opinionated JavaScript formatter

#81

Post by tobr »

davidmurdoch wrote: post #65
Groxx wrote: 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.

That’s not going to work with object keys anyway, which need to be quoted in JSON. You can’t even configure Prettier to do that unless your keys are invalid JS identifiers.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#82

Post by ss3000 »

atombender wrote: post #58
franciscop wrote: post #53

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

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#83

Post by ss3000 »

fictionfuture wrote: post #40
mattlondon wrote: post #33

Earlier quoted context omitted.

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.

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

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#84

Post by k__ »

tlrobinson wrote: post #79
k__ wrote: post #13

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

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.

Really?

I had the impression Prettier follwed the spirit of Go fmt, which had that claim.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#85

Post by j-f1 »

davidmurdoch wrote: post #65
Groxx wrote: 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.

Fortunately, if you use Prettier to format your JSON files too, it’ll quote unquoted properties and remove trailing commas: https://prettier.io/playground/#N4Igxg9gdgLgprEAuEwA6UAEmDOE...

Re: Prettier 2.0 – Opinionated JavaScript formatter

#87

Post by capableweb »

ng12 wrote: post #86

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.

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#88

Post by capableweb »

davidmurdoch wrote: post #64
Waterluvian wrote: post #59

Earlier quoted context omitted.

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.

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.

Re: Prettier 2.0 – Opinionated JavaScript formatter

#89

Post by capableweb »

k__ wrote: post #84
tlrobinson wrote: post #79

Earlier quoted context omitted.

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.

Really? I had the impression Prettier follwed the spirit of Go fmt, which had that claim.

Maybe you're confusing StandardJS with Prettier?

Re: Prettier 2.0 – Opinionated JavaScript formatter

#90

Post by random3 »

globular-toast wrote: post #77
random3 wrote: post #67

Earlier quoted context omitted.

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.

I ran formatters on a largish codebase over Christmas when all the PRs were done. You just have to pick your moment. If it's really hard then get everyone to agree on a date to do it and make it each developer's responsibility to either merge before or rebase after the change. It can be done.

Some team in my old job use to have a term for this - "grabbing the virtual chicken". It was essentially a giant distributed lock :)
Post reply on HN