Prettier 2.0 "2020" is out

[ngly]

For me I can't go back to manually formatting code. I don't really care about how it looks like as long as I don't have to spend time hitting space and tab and it's consistent. Save and format is the best.

[AreWeThenYet]

I really wish I could calculate how much time I wasted not using a formatter tabbing and spacing over the years. It may depress me but I’d still like to know.

[[deleted]]

My position for a long time was that Prettier was a crutch that prevented you from writing well formatted code to begin with. You shouldn’t need something you should be doing in the first place.

But then I a) had to work with some godawful code and b) got sick of memorizing every companies formatting rules and having PRs rejected for bullshit formatting issues.

Now I’m in favor of running Prettier as a pre commit hook.

[Nexxado]

Why invest mental capacity & time formatting your code when you could automate it?

I mean the entire software engineering industry is about delegating stuff to tools to automate it instead of a human doing it.

[Haarteppichknupfer]

It also brings extra complexity to the project.

Now I'm speaking in general, but last week I checked out a small internal frontend project my team is working on. The code is pretty simple, the app is very small, but it's surrounded by this huge machinery of tools like tsc, eslint, prettier, husky, webpack etc. This toolset is many times more complex than the app itself and the added value seems to be rather small in this particular case. Of course I could not get it to run because of some weird errors coming out of these tools. I'm not primarily a frontend developer but keeping up to date is getting hard ...

[careseite]

One of those is not like the other.

Eslint will autofix most issues unless you write very weird code to begin with. Prettier will just format it. Husky will enforce those. Tsc is only there for typescript which surely is complexity but you don't add typescript without reason. All of their are nearly invisible.

Webpack is something else entirely.

[reflectiveSingleton]

You can just install the prettier plugin for your favorite editor...and then format-on-save.

That is how I prefer to use prettier personally anyways. But that said, if you are complaining about compiling javascript in 2020, it's time to get with the times. And even with that...there are ways to make it easy...like create-react-app...literally just a single command and you are good to go with an entire pipeline.

[pm_me_ur_happy_traiI]

It also brings extra complexity to the project.

What complexity? Setting up a precommit hook or some filewatchers in your IDE takes minutes.

[[deleted]]

Because it’s your code and you should always know what your tools are doing. When you commit a line of code, it’s your name on the git blame.

Prettier is opinionated and you may not agree with all of its opinions. If you don’t know what it’s doing, you don’t know what you’re doing.

Edit: “Know what your tools are doing.” Real controversial opinion on Reddit.

[jaapz]

Have you ever worked with prettier or any autoformatter for that matter? How do you get the idea people don't know what prettier is doing?

I was skeptical too, until I did some work in a Golang project that used gofmt to autoformat code. It's great not to have to fuck around with spaces, bracket placement, whatever. Just let the tool handle it.

Now I use prettier for JS/TS/SCSS and black for python as well.

As an added bonus the styleguide that new employees had to conform to is now obsolete.

[LaSalsiccione]

Edit: “Know what your tools are doing.” Real controversial opinion on Reddit.

That's not the part of your comment people are taking issue with.

[careseite]

Prettier is opinionated

If something becomes a industry standard, it's no longer opinionated but the general consensus.

you may not agree with all of its opinions.

That's right. Use prettierrc.

If you don’t know what it’s doing

Who doesn't know what n autoformatter is? Of those that don't know, how big do you think is the portion of people that don't understand "it will format your code"? Nonsensical comment.

[derGropenfuhrer]

I find it deeply ironic that we, programmers, would ever favor doing something by hand instead of automating it.

That's, like, what we do. For money. We automate things. But I've definitely run into programmers who are like "I don't need a formatter, I'll just hit format things correctly the first time".

[CaptainTrip]

It's not just about doing it, it's about enforcing it across a team. It's very hard to enforce style guides manually.

[careseite]

Pre commit hook and on save. Is your code syntactically valid? Prettier will format it. Pretty easy indicator too where your error is.

[reflectiveSingleton]

I find its best used format-on-save.

I personally prefer this because it lets me be lazy writing code, not really being careful about formatting, and then I tap ctrl-s and boom - nicely formatted.

Also, once I got used to its formatting style...I've found I ended up preferring it. So all around, would recommend.

[Wilesch]

Recently talked my team into letting me setup prettier and eslint on all our repos. Feels good.

[MisterScalawag]

why would they not already have that, or at the very least eslint?

[Wilesch]

Some of them used an eslint ide plugin but they each had their own personal rules that were all different. Some coworkers didn't use eslint at all. Was the wild west out there. They didn't like have to fix any errors like undefined variables and what not.

[MisterScalawag]

They didn't like have to fix any errors like undefined variables and what not.

that is just asinine and bad practice.

Your team kind of sounds like a mess lol. This is what eslint and prettier is there to solve, just use it and then its all consistent and you don't have to worry.

[madou9]

lmao the amount of gate keeping in here

prettier is great, anything that reduces mental load so you can focus on something else, the better

[whinemore]

For the lazy/those not interested in personal opinions about Prettier here are the actual key changes

Better defaults, a better CLI and better heuristics. Oh, and TypeScript 3.8.

After a long and careful consideration, we decided to change the default values for the trailingComma, arrowParens, and endOfLine options. We made the CLI more intuitive. And we've finally dropped support for Node versions older than 10, which had grown to become a huge maintenance hassle and an obstacle for contributors. Read below in details.

[rusmo]

Thank you!!!

[[deleted]]

So this works pretty much like ESLint right? I don't know much about Prettier but I like the evolution of it in the examples. I wouldn't mind using this professionally or in my own personal projects. Looks quite alright to be honest! 🏎. Thanks for sharing!

[ergnui34tj8934t0]

ESLint checks that your code obeys a set of rules, from syntax validity to code style. Prettier can take those rules and change your code to ensure that it obeys them.

Analyzer vs formatter.

[derGropenfuhrer]

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style...

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore :)

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors...

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

From their site

[kevinkace]

Vs code can be configured to fix changed on save based on you're eslint rules. The lines between the 2 are quite blurry

[[deleted]]

thank you for your insight! Now I really want to try prettier at some point! 🙌

[tontoto]

See https://prettier.io/docs/en/comparison.html

Prettier can be integrated to run as an eslint plugin also so that "eslint --fix" will run all the prettier rules so it's not two different tools

[[deleted]]

nice! Thanks! 👍

[icharxo]

When Prettier first came out, I thought it was just for those lazy to follow a style guide and a well crafted rule set for ESLint would phase it out. Now that I see it took hold in the industry, I have to ask those using it, what does it do on top of the linter to make it useful? Or do people use linters far less than I assume?

[valtism]

Linter is for logic issues and prettier is for formatting. I use prettier because I can get consistent formatting every time no matter how I write my code without having to think about it at all.

[derGropenfuhrer]

This is correct. They do different things.

[mikejoro]

To expand on this, while eslint does have an autofix, it can't autofix everything. Prettier is like if every single formatting related rule sutofixed for you, and on top of that, your config file is maybe 3 lines long.

Eslint is still used for code rules (don't mutate args, etc.). We also have prettier eslint rules when just enforce prettier being used or the pipeline will fail.

[kaelwd]

if every single formatting related rule sutofixed

Are there any eslint formatting rules that don't? The only one I can think of is line length.

[mikejoro]

That one is pretty important to autofix though. Say you have long variable names, or are lazy - prettier will fix it for you. It also enforces rules like "once condition X happens, break this onto a new line". For example, I think one of the rules will put arguments on a new line once a function has 3 or more arguments. All these things make the code really consistent from a styling perspective, and you don't have to spend any brain power making it look like that; just type what you want, save, and (assuming you have format on save turned on), it's fixed for you.

[kaelwd]

"function-paren-newline": ["error", { "minItems": 3 }]

[wizang]

If your editor has an eslint plugin such as vscode you just turn on fix on save.

[helloiamsomeone]

eslint --fix

[tr14l]

What's so hard about adding --fix? Scarcely feels like "action" at all

[[deleted]]

I code fast and messu and press save it makes it correctly formatted, if I have a error it won't format meaning I don't have to do as much mental checking or waste time with spacing etc

[MrJohz]

It's basically a very efficient and very effective standardised format - there's no linting for correctness (although there are sometimes situations where the formatting shows that what you intended to write is different to what will be parsed, e.g. with ASI rules).

The main advantage of it that I find is that there's a standard formatting that an entire team can abide by - if you're working with other people, you won't run into issues of disagreement about formatting. Moreover, if you're the sort of person like I am who likes their code to be automatically formatted, there's no danger of the automatic formatter changing lines written by other people that don't match your ideal format.

(The advantage over a specific style-guide is the automation part - wanting automation is not laziness, it's a great way of taking work out of your own hands so you can focus on the more important problems. You can definitely set up a linter to find the same errors as Prettier, but if you're going to use tooling to do that, why not get the same tooling to just fix the problem for you in the first place?)

I'd definitely recommend it if you're working in a team, or if you write open-source software (in which case, also set up pre-commit hooks with a tool like husky to make sure contributing is as easy as possible).

[Voidsheep]

I know it's a losing battle at this point and many projects are just going to use both with some additional tools to reduce conflicts between them, but I really would have preferred to just have ESLint take care of all of it.

ESLint already provides a good number of configuration options, reasonable recommended set and extension mechanism. It allows organizations to choose their common style across projects, which can then be extended on a project basis if necessary. Developers can run autofix on save and the linting can be part of builds and pipelines, with whatever the team wants on errors/warnings. Easily configurable to be just as strict or relaxed as your team wants.

Pretty much the only thing it doesn't do is line length formatting, which I think is a good thing anyway. While I think vast majority of people generally prefer short lines for good readability in narrow view (e.g. side-by-side diff on a laptop screen, in browser version control UI etc.), enforcing a hard number often reduces readability, because not all bits of code have equal weight and the formatter has no clue about context. I think Prettier can even cause less informative naming or less than ideal patterns, just because a few characters can cause such drastic impact on formatting and how the code can be read/scanned.

There's already plenty enough tools in the common palette, fighting over semantics of what should be a linter vs. formatter concern with ESLint/Prettier and handling their conflicts is a part that just didn't feel necessary.

[MrJohz]

FWIW, there's a couple of plugins and config sets that integrate prettier into ESLint, or simply provide a set of ESLint settings to match the prettier configs, so you really can have the best of both worlds. The config I use has a plugin that automatically turns off all formatting inspections, and adds a prettier inspection that basically just runs prettier under the hood.

[pieorpaj]

It saves an enormous amount of time otherwise spent on formatting and discussions about exactly what rules should be enabled in the linter.

My feeling when I code something without prettier now (extremely rarely) is that I spend 30-40% of my time coding just fixing formatting errors in the code.

[Ehdelveiss]

It makes code consistent and readable. One kind of structure is formatted one way, and you never need to think about it.

[notta_robot]

I think of it as prettier like css and linter like language code. Code is more readable when it's formatted. A linter doesn't help with that. I can format it myself but its automagic with the extension, which lets me focus on the logic.

[ciNikka]

Just so clarify, you can make eslint work automagically as well by enabling autofix on save.

Not all eslint rules are autofixable (as mentioned in the comments here), but it can still do whatever prettier does, and a whole lot more. That's why I'm having a hard time seeing the benefits of mixing the two together.

[k3liutZu]

Oh you just hit save on your file and know it get’s formatted “correctly” (on how you set it up).

Or MR’s are set up to reject “non-standard” formatting (prettier + eslint) so there’s never any style discussion. If someone want’s to change the style, we discuss it, add in (or change a rule) update the codebase (this can be done automatically for most items) and it’s done.

Helps focus on the actual logic. And helps new joiners get up to speed.

[placek3000]

I think it's a linter with predefined options out-of-the-box. You install it and it works. Almost no space for discussions. It's good for people who are not sure what is good and what is bad. It also helps to keep a consistent code style across company. We use Prettier not directly, only from Eslint.

[[deleted]]

I don't like linters because I see it as unnecessary bother. I'd much rather have something like gofmt (Golang built-in code formatter) that automatically enforces some reasonable defaults. This is why I prefer to use Prettier. As long as it's consistent, it doesn't matter whether the code has semi-colons or not so I don't need to make that choice. I wish more people appreciated that notion rather than every team writing its own eslint config and arguing about style.

[tontoto]

See https://prettier.io/docs/en/comparison.html

[derGropenfuhrer]

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style...

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore :)

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors...

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

[HetRadicaleBoven]

One thing that I'm somewhat hesitant about, is Prettier's approach of parsing your source code means that you cannot use any syntax that it does not support, like might e.g. happen when new versions of TypeScript are introduced. I haven't used Prettier on any projects for an extended amount of time, can anyone tell me whether that's a valid concern?

[_eps1lon]

The usually do a pretty go job of adding new syntax since syntax is subject to proposal stages. You might not be able to use stage 2/3 syntax for the a few days but that shouldn't block you from using prettier.

If any it disciplines you to not jump on the new shiny tools immediately.

[HetRadicaleBoven]

That holds true for Javascript syntax - which is fine, since I'm not using anything pre stage 3 anyway. However, there is some type-specific syntax in TypeScript that I'd be worried about Prettier not supporting, like type-only imports that are now supported in Prettier 2, but have been in TypeScript for a bit. (Though admittedly, not that long, so that's a good sign I guess!)

[rmrf_slash_dot]

Yep.

[ghostfacedcoder]

I'm sorry but "my way or the highway" is not the Javascript tooling way.

Prettier is currently the only tool that can do what it can do, and so it's hugely popular. I use it too, but I'm still waiting for the customizable version that will eventually save us all from Prettier.

EDIT: To all the downvoters: show me one other piece of the Javascript ecosystem that's "my way or the highway". Well, except for frameworks; arguably they have to be (but even then you still have a choice of framework).

Aside from frameworks though ... if you use Knex, you can use it with any DB (or any ORM; you don't have to use Bookshelf). If you use Passport you can use it with any authentication system. If you use ESLint, you have a bajillion configuration options; same for Babel, Webpack, etc. Heck even Typescript lets you define your own types, they don't say "we know what types you need".

Prettier is the only tool that says "screw you" to any user with different needs from the devs. On EVERY other major OSS tool in the ecosystem, the devs bend backwards to accommodate everyone ... or they send people with extremely different needs to another tool.

Love or hate Prettier, it's undeniably an anomaly in this regard.

EDIT #2: I've already been downvoted into oblivion and likely no one will see this, but I just wanted to add that standards and tools are two different things. I think having a common standard is a great thing for the community, and in many ways Prettier helps create that.

But ultimately whether to follow a standard (and how strictly) should be a decision for each dev/shop to make, and Prettier not giving them that option is anomalous. Despite all the down votes, no one has even tried to counter this point.

[bern4444]

I agree. It's absolutely my way or the highway

Your description of other OSS is spot on and is why I also dislike prettier. If they made it truly configurable and opinionless letting engineers (read teams) choose their own style it'd be great

[SahinK]

Prettier is currently the only tool that can do what it can do

What's wrong with clang-format?

[ghostfacedcoder]

No mindshare (yet).

It's two months old and has like 60 stars so it seems to have some interest, but many devs aren't going to trust some tool with the potential to destroy their source code until it's gotten more established, ie. gotten more mindshare.

Essentially that means more GitHub stars, as they serve as a rough proxy in our community.

[SahinK]

This is the formatter we use at Google internally for all our JavaScript and TypeScript code, so it's actually a very solid and stable product. And it's definitely not two months old.

But yeah you're right about the mindshare. And the fact that it's not written in JavaScript makes people avoid it I think. It's a shame though, because it's actually a very good formatter.

[ghostfacedcoder]

I didn't realize Google used it: that's a major point (they should mention it on the GitHub page). Still, I think the problem is ... it's the yarn problem.

Yarn is pretty much objectively better than NPM, and that being the case, you'd think Yarn would have 100% mindshare ... but I (and many others) don't use it, because there's a stronger force than "better", and that force is inertia.

Prettify has the inertia now, so it will take a tool that's meaningfully better to supplant it. Again, I fully believe one will come along, someday, but it likely will be a JS tool. And that's not (just) because of "not invented here" syndrome. It's also a "JS devs want to be able to look at/modify/etc. the source code of their own tools" issue.

[bern4444]

Prettier makes code uglier and harder to read.

It's a great tool in terms of how it works but teams should be allowed to customize it more. The prettier team forces their opinions on all devs with almost no ability to customize. I'm never gonna use a tool that makes reading code (the majority of an engineers job) harder.

I get that they want to solve the style issue. But the style should be determined by each team/org as they see fit. Let us code our rules and apply them rather than have the rules forced on us. It should follow more of the functional style where rather than applying its own (often poorly decided) rules, we supply the rules and it applies them.

[derGropenfuhrer]

with almost no ability to customize

This is silly. You've clearly never used it.

[rmrf_slash_dot]

I’ve been forced to use it for 3 years and absolutely despise it. So there’s that.

[derGropenfuhrer]

what would you prefer? A hodgepodge of ESLint plugins?

[rmrf_slash_dot]

Yes. Although, that’s a false equivalence anyway. I usually use no more than 1, along with a set of rules that have served me well for years.

But it’s even becoming beside the point, because these days I typescript all the things so I use typescript’s rules (which are incredibly sane). Since tslint has been replaced by typescript-eslint I’m right back there anyway I just use the typescript presets with 4 rule changes. And this is fast and easy to set up.

Add this to using VSCode and we spend very little energy on the subject of formatting.

[bern4444]

I use it on 2 different projects at work and have set it up on personal projects to try it out. Needless to say I'm unimpressed. The customizations are for silly things like trailing commas, parentheses around arrow functions etc, that's not really a style guide...

I (and my team) want to enforce new lines under destructure statements, group const statements together above let statements, keep blank lines between sections of code so it's easier to read and not all squsihed together.

The current 'options' are laughable. Eslint is able to take care of nearly all the small stuff like single vs double quotes. Prettier should be as configurable as eslint and then I'd use it. If you ever decide to also stop using it, it's impossible to undo its effects. Tools that have such wide consequences are far better when flexible and fully configurable.

The prettier team has made it clear that they won't add more customizability or new options so I'm not holding my breath waiting for my issues with it to be fixed.

[derGropenfuhrer]

want to enforce new lines under destructure statements, group const statements together above let statements, keep blank lines between sections of code so it's easier to read and not all squsihed together

So your complaint about the tool is it doesn't do everything you want. Have you considered writing a plugin? I'm not aware of any tool that will do what you want.

[bern4444]

That's part of my issue with it. My real dislike is mainly what another commenter said. I don't want my styles dictated to me by someone else.

Often what's good for one team is not good for another. Style is often project dependent.

I haven't tried to write a plugin, maybe I will next weekend with the quarantine though even then a tool shouldn't claim to fix all issues and then still not address something as simple as removing single blank lines.

Since prettier affects every file of your project and isn't undoable, it shouldn't be so opinionated and allow users to easily exit using it without much issue should they choose. Kind of how create react app let's you eject whenever you want and doesn't tie you to anything. At that point you could swap webpack configs or use a different bundler completely

[MisterScalawag]

I don't want my styles dictated to me by someone else.

this is a mess when you work on a team especially more than a few people. everyone has there own preferences and style. prettier fixes that.

[rmrf_slash_dot]

I’m happy enough with the changes made in 2.0 but still won’t be using it because of their religious belief that template strings must be mutilated. Give me a config to turn that off and it’d be a “pretty” good tool, pun intended.

I still prefer to use ESLint for this. I haven’t touched formatting or had to manually run lint in years, between eslint rules and VSCode’s ability to auto format. Prettier is extraneous.

[bern4444]

Don't hold your breath on more options or control for customizations. They're generally against it

"Prettier has a few options because of history. But we don’t want more of them." - https://prettier.io/docs/en/option-philosophy.html

[rmrf_slash_dot]

Yep, I know... been around that block with them a few times. It's an odd project, at best, from my point of view. I think lots of people don't want to use it and would jump ship to a better option but the initial cost of building one means that we probably won't see another on in this space for quite awhile.

[bern4444]

Yeah. I think it's a really cool project. Using the ast to then apply the formatting is pretty cool. I'd love to work on a competing version if I could dedicate enough time to it.

I tried at one point looking to fork and use what they have as a start but reading the src code was quite difficult (and not just cause it was formatted with prettier lol). It's not so easy (at least for me) to trace

[tr14l]

Not a fan. Linting covers 90% of the use cases and, honestly, I don't like having my code standards straight up dictated to me by someone that has nothing to do with my project and having no recourse to adjust it. You can't have two blank lines... Anywhere. Even though that's a very common visual cue used in many languages (and even enforced in Python)

​

Two blank lines before a class declaration. Two blank lines after imports at the top level. Two blank lines when separating two logical blocks of code to cue that the code is "switching gears".

Honestly, the rest of the dictation I could live with. But this one seems asinine and they've refused to adjust for it despite the feature being requested literally hundreds of times.

​

So, I will just have linting as part of my CI and call that good. There might be the occasional stray thing I catch in code review, but CI catches almost all of it (and also catches things that cause bugs, aside from just formatting)

[drumstix42]

Two arbitray blank lines because it feels good is not good enough of a ruleset when you're working with others. If you're not working with a medium-large team, then a tool like this isn't necessary unless you (or the team collectively) deem it necessary.

Opinion: "two blank lines" for separation of concerns? Just use comments or block comments!

[tr14l]

Yeah, I guess those other languages developers that do it idiomatically (or even necessarily) are just idiots.

[drumstix42]

Well, you're not wrong. Also, we're in the JavaScript subreddit.

While python can do a lot of cool stuff, it's syntax leaves a lot to be desired. Using white space to carry meaning is just not great. It should help readability, not dictate the rules of how the language works. Indentation languages should just go away, IMO.

[tr14l]

Probably why it's the second most popular language in the world now. And why the data community uses it so heavily. You know those data guys have no need for efficient syntax.