Live data from Hacker News

Prettier 1.0

jlongster.com

21–30 of 78 posts

Re: Prettier 1.0

#22

What is the Prettier equivalent for SCSS and HTML?

I don't know that there is one. From the repository README:

> Prettier bans all custom styling by parsing it away and re-printing the parsed AST with its own rules that take the maximum line width into account, wrapping code when necessary.

Re: Prettier 1.0

#23
post #18
post #2

Prettier goes such a long way to enforcing standards on a language and ecosystem which otherwise has none or few. What standards do exist are frequently arbitrary, or enforced by legacy code at random companies. For example, the Airbnb JS style guide [1] recommends single quotes in JS, but double quotes for JSX properties. Why the difference? Why not stick with double quotes everywhere, as they are required in JSX bl…

One of the Airbnb style guide authors here. The point about quotes comes up often. The important part for us is consistency at Airbnb. We use eslint to enforce and maintain the consistency. Would it be more consistent to treat strings the same everywhere? For some projects sure. We diverge from the community a bit in the sense that we treat JSX as not JS and we aim to be consistent about that. If your project treats…

Pretty Diff contains an option to convert string quotes to either double quotes or single quotes. This was a trivial update and I would be amazed if its absent in other beautifiers.

Re: Prettier 1.0

#24

I was waiting the --no-semi option to start using Prettier. Thanks to the team!

The option seems to put semicolons at the front of your code instead of at the end. Am I wrong? Why is this attractive?

Re: Prettier 1.0

#25
I feel like you have to give Go credit for exposing this type of productivity hack. Once you gofmt/goimports on save you will never go back.

Edit: If I had to program in JS I would definitely use this coming from Go.

Re: Prettier 1.0

#26
post #13

I can't overstate how freeing coding with prettier has been -- often I'd find myself quickly grokking something and once I finally got it to "work," make sure it was all styled properly. Since using prettier, these things are one-and-the-same, which is a tremendous gain.

Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement isn't just a "I think it should be done this way..." but "I actually understand code better when it's written this way..." If we were to implement prettier, and chose to use 2-space indents, for a simple example, how would a 4-space developer fare when they pull…

You just have to settle on a style as a team and stick to it as a team. I'd say it doesn't make a ton of sense to have individual coding standards among a team.

Re: Prettier 1.0

#27
post #13

I can't overstate how freeing coding with prettier has been -- often I'd find myself quickly grokking something and once I finally got it to "work," make sure it was all styled properly. Since using prettier, these things are one-and-the-same, which is a tremendous gain.

Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement isn't just a "I think it should be done this way..." but "I actually understand code better when it's written this way..." If we were to implement prettier, and chose to use 2-space indents, for a simple example, how would a 4-space developer fare when they pull…

That doesn't sound like a good idea (after all, there can only be one codebase in source control) but I believe it actually would be possible – and in fact, prettier would be a vital component to making it happen.

If you have a pair of particularly persnickety peers, you could theoretically:

1) run prettier with the company-wide config as a precommit hook (https://github.com/prettier/prettier#pre-commit-hook-for-cha...)

2) instruct your colleagues to have their editor run prettier with their own preferences on save.

This way, your colleagues can simply open a file locally and save it to see things their way – and the code will be back to company-normal when they commit. They'll still have to see that unbearable bracket-spacing during code review, of course.

Prettier doesn't have many configuration options (intentionally!) so they'd probably opt to use prettier-eslint or similar, which allows more configuration (at the cost of speed).

Hopefully, after trying this, they would come to the conclusion that life is better just using the defaults, two-space-indents be damned. Bikesheds are great places for compromise.

Re: Prettier 1.0

#28
post #24

I was waiting the --no-semi option to start using Prettier. Thanks to the team!

The option seems to put semicolons at the front of your code instead of at the end. Am I wrong? Why is this attractive?

The example you found on the blog post was there to show how prettier handles conflicting cases. It will print them only in those cases.

Re: Prettier 1.0

#29
post #13

I can't overstate how freeing coding with prettier has been -- often I'd find myself quickly grokking something and once I finally got it to "work," make sure it was all styled properly. Since using prettier, these things are one-and-the-same, which is a tremendous gain.

Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement isn't just a "I think it should be done this way..." but "I actually understand code better when it's written this way..." If we were to implement prettier, and chose to use 2-space indents, for a simple example, how would a 4-space developer fare when they pull…

I suppose Prettier should make it possible for a developer to reformat the code the way they prefer when they pull it, work on it, then format it back to what the rest of the team has agreed on before they push. Unless it was completely automated it sounds like a pretty terrible way to work, though.

How are you doing it today?

Re: Prettier 1.0

#30
post #18

Earlier quoted context omitted.

One of the Airbnb style guide authors here. The point about quotes comes up often. The important part for us is consistency at Airbnb. We use eslint to enforce and maintain the consistency. Would it be more consistent to treat strings the same everywhere? For some projects sure. We diverge from the community a bit in the sense that we treat JSX as not JS and we aim to be consistent about that. If your project treats…

Pretty Diff contains an option to convert string quotes to either double quotes or single quotes. This was a trivial update and I would be amazed if its absent in other beautifiers.

Yes, prettier has a `--single-quote` option (default false).
Post reply on HN