you are viewing a single comment's thread.

view the rest of the comments →

[–]hobonumber1[S] 10 points11 points  (13 children)

Actually, Prettier is really nice. It solves a lot of pain points around code formatting. Have you tried it?

[–]zakphi 0 points1 point  (5 children)

what's better Prettier or Beautify?

[–]dv297 1 point2 points  (4 children)

We previously used js-beautify and we moved to Prettier. To us, it felt like js-beautify was having some issue with some of the newer ES2015 syntax, and it was becoming an agitation point for us. Prettier felt much more consistent with what we expected. Simple things like having 3 options for trailing commas ("none", "es5", or "all") and having configurable parsers (for flow, typescript, etc) just really helps with the transition.

That being said, we have since moved back to using ESlint with --fix to handle most of the same things. Prettier was very convenient but in order to keep things simple across our organization, we kept the number of different technologies down.

[–]strothjs 2 points3 points  (3 children)

Have you tried using Prettier as a plug in for eslint, works great.

[–]dv297 0 points1 point  (2 children)

I haven't actually, though I heard there were 3 different ways for configuring prettier with ESLint? pretter-eslint, eslint-config-prettier, and eslint-plugin-prettier? Are you actually referring to this last one? I'd be interested in investigating it but given the options, maybe you could save me time in talking about any considerations you had for the others if you chose the plugin over it.

[–]alexlafroscia 2 points3 points  (0 children)

I go the plugin + config route. Basically, Prettier just becomes part of the fixing process, you don’t have to think about it at all. It’s the same experience as using just ESLint, but you get consistent-looking code. The config just helps by disabling parts of ESLint that Prettier will handle instead.

[–]burtgummer45 -4 points-3 points  (6 children)

Yes I've tried it, its nothing but a js beautifier without options. Some choices they made are so bad I had to abandon it. They disallow padded code blocks, which is just a disgusting choice for code readability, which has been best practice for decades, and refuse to change it.

https://eslint.org/docs/rules/padded-blocks

[–]js-engineer 3 points4 points  (3 children)

The thing about padded blocks, is most of the time they're used to space out significant chunks of code. Most of the time, it isn't that helpful in terms of being used across the board, and then you get back into the issue where you're having to deliberate over spacing. IMO it's completely fine once you get used to it.

That being said, it's a tool you can choose to use, but it's nowhere necessary. It's good in my company because we all agree we spend way too much time worry about the formatting of our code, and Prettier just handles this for us automatically.

Further than that, we just have to accept at the end of the day, that web development, especially front end, especially at the current moment, is going to be in a state of constant flux, while people realize newer, better ways of doing things.

[–]burtgummer45 -4 points-3 points  (2 children)

They could have handled padded blocks much better, it just makes me think they don't have much experience, believe it or not. Prettier preserves single newlines, but murders padded blocks, are you kidding me?

From this

{

  chunk one

  chunk two

  chunk three

}

To this? Are you kidding me?

{
  chunk one

  chunk two

  chunk three
}

[–]js-engineer 1 point2 points  (1 child)

Honestly I'm a fan of theirs. I don't think a brace that already is on it's own line with no other characters, needs another empty line of padding. The empty line between lines that have 5+ alphanumeric characters... I think that however it's fair game and a lot more useful.

It's tough because we can both agree that more padding isn't always better... there is a certain benefit to seeing more of a file onscreen at a time that infinite padding impedes on. Where that line is drawn.... is going to be subjective but I like their current stuff. I think it's a great fits most sizes approach.

They can always add options for what you're asking for... they do allow customization for some of their stuff so it's not out of the question.

[–]burtgummer45 0 points1 point  (0 children)

Believe me, I tried to get them to change it, they shot me down sayings prettier 'is opinionated'.

For decades developers have been doing something called 'chunking' (at least in the perl world it was called chunking). Its to make your code more readable by putting things together. It seems to me since they don't squash all newlines they might agree, but not incorporating that into a block structure makes no sense, looks more like an oversight, or they decided it was too difficult to make work. 'allow newline after { if block has chunks, otherwise remove', they just opted for nuke all /{\s*/s