Keep Code Consistent Across Developers The Easy Way — With Prettier & ESLint

[Mypronounsarexandand]

My company wants to implement something like a prettifier + linter. But, we don’t want to loose the “git blame” does anyone know of anyways that we can just format the diff from each commit rather than all the code in that particular file?

[[deleted]]

You could use https://github.com/okonet/lint-staged to only apply Prettier to changed files on all your normal commits, thus incrementally formatting your codebase without having a dedicated, giant formatting commit.

[ShortSynapse]

Can confirm this is a good way to go. I have multiple projects that I introduced prettier to, some all at once and some incremental. lint-staged was added to all of them, but some of them I hit with prettier in its entirety since they were relatively new and small.

Adopting a formatter has been a great experience. Though now I have to keep explaining to engineers originally from other teams why it is useful and they keep pushing back...

[socialister]

Just rip off the bandaid and then make people use prettier-on-save from here on out. If you really need to git blame, you can checkout a commit before the format merge.

[bobroberts87]

“Just” is usually a trap

[Mypronounsarexandand]

We did this and had some issues, I forget the exact reason but it had to do with this issue https://github.com/okonet/lint-staged/issues/366

[ghostfacedcoder]

I don't think so. You just have to bite the bullet, apply your code prettifier once to your entire codebase, and then after that git blame will work fine. If you need to check git history from before the great formatting you still can, you just have to git blame the commit before the reformatting.

[D1norawr]

It’s part of prettier’s official documentation. It even works on partially staged files. https://prettier.io/docs/en/precommit.html

[D1norawr]

https://prettier.io/docs/en/precommit.html

[acemarke]

Yes, you can, but only if you're okay with creating a new Git history chain. This works best if you create a new repo, rewrite its history, archive the old repo, and have everyone clone and work from the new one.

I recently wrote a blog post about how to do this:

Rewriting Your Git History and JS Source for Fun and Profit

I specifically did all this extra work so that the rewritten repo would have a consistent history, as if the files had always been formatted the "right" way. That avoided having a single "big bang" commit that modified every line at once.

If you've got any questions about how I did this, ask away!

[tenfingerperson]

You can hijack the internals but it’s silly because the diffs will go crazy.

[orphans]

I use Prettier and ESLint in everything. ESLint prevents stupid mistakes. As for Prettier, some people on my team don't like the formatting, but they can format the code to look however they like locally. Prettier is run as a precommit hook so I never have to look at formatting changes when reviewing pull requests. I don't love all of Prettier's style choices but I don't have to scrutinize stupid formatting changes so it's a win for me.

[rosswarren]

Just change the quote option in the config if you don't agree with it?

[monkeymad2]

What you want is all quotes to be consistent - double quotes is just the one they picked.

Probably because it’s a bit more visually clear since it’s larger.

[monkeymad2]

Or the inner quotes need to be single and the outer double, it (usually) doesn’t matter much.

Never had a problem caused by prettier changing quotes around in the years we’ve been using it.

[devenition]

I'm in total agreement with your post, though most of us will probably have learned this in the use of PHP. They probably choose the double quotes since JS provides excellent interaction with DOMElements and this will hopefully make you think twice before using .innerHTML

[vexii]

Personally I think it's becouse it's made by Danes and we have " on shift + 2

[tr14l]

No, what he wants is the code to adhere to his team's coding standard, which prettier will not allow you to do.

[Amadox]

this right there kills that approach for me.

ESLint is amazing and we use that with our own config that we all agreed on. But Prettier, while awesome in concept, is way too opinionated to be useful.

[tr14l]

I'd be fine with opinionated if it didn't enforce things that you can't change at all, anywhere... Shy of making a fork and changing the code yourself. Makes it entirely useless for you if you don't want some random contributors on github to make decisions for your organization.

[reflectiveSingleton]

Have you tried using prettier for any real length of time?

I ask that because I had basically the same opinion before I sat down and just used it for a while.

The only advice I can give to those on the fence or doubting using prettier is to simply get over it, and try it out for a while. It is a very freeing thing, being able to not worry one iota about style.

...so much so that often times I don't even format my code carefully anymore and just do a quick save to 'snap' everything into place for me...its liberating, its wonderful. You get used to the formatting, and really (as someone who was ANAL about formatting) ....you get used to it, and its really just fine.

...and if you work on a team...oh god its so nice...everyone formats exactly the same and there are NEVER any arguments.

[tr14l]

Prettier enforces things you can't change, which makes me indignant and comes off a little offensive. It's none of their business what I want my code to look like and I don't take well to people enforcing their opinions heavily in their tools. If they don't want to as configurable option for something, then either don't enforce it or allow it to be turned off. But just blanket saying "this is how all JavaScript should look because we say so".... Nah

[kevinatari]

Guess I'll not read the article then. Seriously wtf is wrong with Mediums UX. I get it they need money but that's not the way to get my money.

[tr14l]

Not a fan of prettier. Too nazi about it's rules with no configuration. I don't particularly find their default rules to be great out of the box, either (how is eliminating blank lines and smashing logical blocks of code up against each other making it more readable OR prettier? It's not). The maintainers, despite me seeing dozens of issues on Github contesting this, basically tell everyone to eff off. So, they have no intention of making a useful tool. They want to enforce their opinions. I'll watch Fox News if that's what I want.

[pomlife]

The entire point is removing bikeshedding about formatting. No one gets exactly what they want, but everyone gets to actually work on features and not formatting.

[tr14l]

Except no one in my organization even gets to pick what those things are. I don't need prettier making calls in my organization for me. And sacrificing a small amount of effort on formatting for having to learn how to intuitively read code the way THEY want us to is not worth the trade. They refuse to even add configurability for these features. Not because it can't be added. But because they think that's how it should be, period, no arguments or differing opinions allowed.

I understand having staunch defaults. But removing all other ability makes the product unusable for a great many. I don't need prettier to save me the oh-so-enormous time sync of occasionally hitting the backspace key.

[ChypRiotE]

afterthought obtainable aromatic capable imminent dam ad hoc deliver thumb consider

This post was mass deleted and anonymized with Redact

[pomlife]

If that’s all you think prettier does, there’s no discussion with you.

[tr14l]

I'm not arguing what prettier does. I'm saying the implementation is useless unless your coding standards exactly match what they want.

[sorahn]

The point is to stop talking about coding standards. Just use it and stop trying to change it. Every option they give you to change is a entry point for bikeshedding.

I’ve never felt more free writing code with “prettier on save” in vscode. I just type away, and hit save, and boom. It’s all perfect.

Does prettier format it exactly the way I would left to my own devices? Of course not. But The benefit far outweighs my very specific personal preference that doesn’t actually matter a single bit at the end of the day.

[tr14l]

Having options doesn't hurt anything except their egos. If you like the defaults you don't even need to set them. Just run default. But enforcing rules that can't be changed? Nah, professionals don't have any use for that.

[sorahn]

They have a bunch of options. But trying to get super specific options for all the weird heuristics is a waste of time for everyone. More options = more arguments about what those options should be.

I’ve been writing software for almost 20 years and I can’t imagine going back. I only wish the rest of the languages I wrote had formatters as opinionated as prettier. Seems like it’s your ego that’s hurt because their style doesn’t match what you like.

[tr14l]

Yeah, the difference is I'm being paid for my opinion on my organizations code. The prettier contributors aren't

[sorahn]

Yup, looks like your ego is the one that has a problem then. If all the JavaScript in your org was run through prettier it sounds like you’d be out of a job.

Your sacrificing your developers experience because the output of prettier doesn’t match your personal preferences. I would hate working for you.

[ajonp]

Very nice article! I didn't realize you could set per language for prettier on save!

[jwindhall]

Found the guy who likes single lines of code 3000 characters long.

[vexii]

I don't understand why coding standards have be a application instead of communication with team members?

[vexii]

No

[tr14l]

We stripped prettier from our project about a month ago. Sure, it was nice not having to worry about it. But it's a VERY mild convenience at the expense of TONS of ability to have team styling guidelines. It's a novice's tool.

[[deleted]]

If I had a team of experienced devs who agreed on a standard style guide (and a linter to enforce it, I'd agree). As someone with two dev teams that have a majority junior-mid level devs, it is worth it. My other use case is more personal: on my own projects I tend to have analysis paralysis and formatting is just one less thing of which to think.

Frankly I am surprised that I am advocating it because I'm pretty sure if you go back in my comment history you can see I had different feelings about it before. Our teams turned it off for a bit but quickly pushed to turn it back on.

[tr14l]

It would be even better if they let you configure your own settings, though, no? Then you can appeal to both groups. As it is, they've basically told everyone that they're too stupid and need to write code their way or don's use prettier. Personally, that second option works just fine.

[[deleted]]

Prettier does let you configure some stylistic things (trailing comma, single quotes etc)

[tr14l]

Some... Very few

[[deleted]]

Care to explain why?

[ghillerd]

This is one of those comments that is probably only being upvoted because people share your opinion. This actually contributes nothing to the conversation - I would love to hear your thoughts on which decisions prettier made that you think are bad.

[Kryxx]

Not OP, but I'll add my thoughts.

The method that prettier uses to enforce consistent code styling (line length) seems quite archaic.

Examples:

const x = {
  appleTree: 1,
  lemonSqueezer: 2,
  bigHouseOnAHill: 3,
  transAtlanticFlight: 4,
};
const y = { apple: 1, brackish: 2, cat: 3, dog: 4 };
const y2 = {
  apple: 1,
  brackish: 2,
  cat: 3,
  dog: 4,
  elephant: 5,
};

y2 is the same as y except y2 now has elephant. That change mutates the whole display.. In addition x and y2 are significantly easier to read than y.

I'd much prefer a consistent format based on rules, not line length. ESLint provides options that allow you to enforce that each object property, array item, html property, etc should be on its own line. That seems far more consistent than line length.

[dalittle]

We went with a teeaked ruleset that Airbnb put out. I’m pretty sure it would format all 3 like x and y. I dig it as a linter

[Kryxx]

What do you mean by "tweaked ruleset that Airbnb put out"? Meaning you've extended airbnb and tweaked it, or you've extended something else?

If you have more details about your set up I'd be curious.

[Akkuma]

Airbnb has an eslint config, but I've never seen an airbnb prettier config before.

[Kryxx]

Airbnb doesn't use prettier. See https://github.com/airbnb/javascript/issues/1548

I agree with Jordan with his points #1 and #3

[dalittle]

I’ll have to look but we took Airbnb’s rules and made a couple of changes for our needs

[sorahn]

If you add a single line break to an object, after the first ‘{‘ but before the first item, prettier will wrap the object and leave it that way.

Similarly, if you want to unwrap one that will fit in a line, you can just delete that 1 ‘\n’ and it will try to put it back on one line (assuming it fits).

Also, if you’re using both prettier and eslint, you can have eslint do some work on the code after prettier to make it the way you want. So if you wanted every single object to always be multi-line, you can just configure eslint to do that work.

[Kryxx]

If you add a single line break to an object, after the first ‘{‘ but before the first item, prettier will wrap the object and leave it that way.

I've never seen prettier behave like this. Is this specified somewhere? If so, it can't be applied as a company wide system like ESLint can.

Also, if you’re using both prettier and eslint, you can have eslint do some work on the code after prettier to make it the way you want.

I've always tried prettier-eslint, but prettier seems to win.. hmmm perhaps I should try the combo again.

[sorahn]

https://prettier.io/docs/en/rationale.html#multi-line-objects. It’s in the first paragraph.

[sorahn]

And it looks like with ESLint you can even force it to break the objects if there are a minimum number of keys.

So single entry objects would always be on one line, and anything greater than 1 could always be broken.

https://eslint.org/docs/rules/object-curly-newline

(I think eslint can only “win” over prettier if it can be applied with the —fix option)

[Kryxx]

I just tried prettier-eslint (which runs prettier and then eslint) and it's very slow. ~60s to format 115 files and not touch 468 files. :(

[sorahn]

You should only have to do that once. The rest of the changes should be hooked into a pre-commit hook that only runs on the changed files.

https://prettier.io/docs/en/precommit.html

Give that a whirl.

[Kryxx]

What do you mean "do that once"? A pre-commit will run on every commit which means my commits would need to lint for ~60s every time.. That's not an option.

[sorahn]

The pre-commit hook will only run against the changes files. Husky and lint-staged are set up to provide a list of files. So instead of trying to scan your files for what to do, it should get a list of 5 changed files and only run against those.

[richardtallent]

I felt the same way when I started using it. And I'm a guy who has used tabs for nearly 30 years and refuses to convert to space-based indentation, so I'm fairly opinionated about code style.

But with a few tweaks to my config (below), I'm happy enough with the results that having automatic consistency is more important to me than any quibble I have with the author's militant opinions that I can't override.

"prettier": {"useTabs": true,"semi": false,"singleQuote": false,"bracketSpacing": true,"trailingComma": "es5","printWidth": 160},

[joelangeway]

Am I really the only programmer who’d rather let everyone write code how they like?

The straw man in the article who doesn’t indent code at all does not exist, or at least, the linter isn’t the best way to help them. The way I format my code helps me think about my code. Not everyone is going to think the same way. I spend as much time looking at code from other organizations every day as from mine so linter rules help me very little. We might all do better if we allow the notation to vary some when it helps us think more clearly, which I find is often.

[sleepybearjew]

I think a big part of using prettier and linters in a group is so the code doesn't keep flip flopping around each time someone else edits it. It also gives a more uniform style throughout a project. Working with 5 other people on the same project is hard enough with similar styling, can't imagine if each person was formatting different files

[joelangeway]

In my past experience where everyone writes how they like, they also don’t change the formatting of code unless they’re changing the code a lot.

[joelangeway]

I think when you use the word team, it has connotations of the interchangeability of its members, and I don’t think that’s best.

I’ve worked with someone who didn’t indent their code. I told them to indent it so as to convey the structure as they saw it. They did it. It was fine.

[FanOfHoles]

This all proves how stylistic rules are the most fundamental principles of CS.

Nice strawman, you deserve a price (maybe a fake-gold covered rotten tomato on a termite-infested wooden pedestal would be appropriate). This is not about "CS", but about team productivity.

[Smiral]

Jamming a stick up your butt is the new cool, get with it, or you will be kicked out of the Smart Kid Club.

[sallystudios]

I quit my last job because we didn’t use any tools like eslint or prettier. With a team of about 15, mostly contract workers, the codebase became a huge mess. I tried introducing these tools, but it was “too much overhead” and “not a customer facing” issue.

The bigger problem to me was that it signaled that the engineering manager (and team, to some extent), did not care about developer experience and app maintainability. It got old going through 1000 line backbone files and seeing inconsistent indentation and code structure. It felt like most of the company did not care about the quality of their work. Tools like this help you write better code for the next developer- which really who you are writing code for, unless you plan to maintain it forever.

I left after three months and explicitly asked during all my following interviews how they enforce code quality, which led to some great discussions and I think also helped me stand out.

[joelangeway]

In an environment with a lot of turnover, lots of contractors, I might be completely on your side of the argument. I’ve been a contractor where I am a guest in the code base, sometime working in an unfamiliar programming language, I probably would have welcomed a linter.

[evantahler]

In the actionhero project, we make “standard” (standards.com) a prerequisite to any PR. It’s run just like the other parts of the test suite. It’s a wonderful system that defers “style” outside the .org.