Live data from Hacker News

Prettier 1.0

jlongster.com

51–60 of 78 posts

Re: Prettier 1.0

#51
post #9

Prettier is a code formatter for JavaScript, like the hugely popular "gofmt". Highlights of the 1.0 announcement: - production-ready (and used, eg; React, Oculus, Cloudflare, etc) - --no-semi option - --use-tabs option - parens that help indicate precedence - many formatting improvements There are a ton of edge cases in this work that really matter (read through the announcement for a few). Speaking as a contributor,…

We had configurability in early versions of gofmt but realized it was a mistake and kinda missed the whole point of having a code formatter, so we removed them.

The problem with doing the same in JS is that the language has been around much longer, and wasn't designed for use with a formatter. ASI failures is a great example.

Prettier has so far resisted configuration wherever possible; it has 8 options, compared with eslint's 260+.

Re: Prettier 1.0

#52
post #11

How does Prettier compare to https://github.com/millermedeiros/esformatter , https://github.com/beautify-web/js-beautify , https://github.com/jedmao/codepainter , https://github.com/rdio/jsfmt , etc.? Personally, I use TSLint with the tslint.autoFixOnSave VSCode setting, and couldn't be happier.

I think you could be happier but just don't know it yet. :)

Every lint ruleset I've ever used still leaves a TON of formatting discretion to the author – notably about where to wrap. Prettier will format code differently depending on how much space there is left to work with on the line – like a human would do, but always consistent.

Re: Prettier 1.0

#53
This is getting closer to my dream setup of being able to open files in my formatting, and saving them in the team's formatting.

Formatting source code feels like a complete waste of developer time and energy, especially when they don't agree with how the team has decided to format the code. I almost wish source code files could be just serialized ASTs and that a VCS could understand them making merges etc. even easier.

Re: Prettier 1.0

#54

It would be useful to compare with "eslint --fix" given Eslint can already reformat (on top of linting non-style things, and projects usually already have Eslint settings).

I use prettier-eslint which (as dahjelle posted) runs prettier (for spacing) then eslint (for syntax fixes). I absolutely love it.

Re: Prettier 1.0

#55
I love this thing, have it on auto save. It saves so much time. Now I can write remove a nesting, leave dangling commas and I don't have to even waste a second to clean it up. Just hit save and everything slips into place.

Re: Prettier 1.0

#56
post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

You might be surprised at the quality of the output (obviously I'm biased). We've tried to choose what most people consider to be the best way to style code, and many times prettier ends up formatting complex code better than I would have manually. Also, the biggest benefit that a lot of people don't realize is it allows you to quickly restructure your code easily: http://jlongster.com/s/refactor.gif

I understand if the way prettier formats your code is not the way you would like, and is more of a hindrance than helpful. But I hope the above gif shows why it is freeing for a lot of people.

Also, note that prettier does keep the original blank lines in your code. That's where most of the rhythm comes from, and we allows authors to group code however they want. The rest of it is basically choosing whether to insert a space here or there or not.

I respect your work, antirez, and I hope you at least try it once! It's totally fine if it's not useful for you though.

Re: Prettier 1.0

#57
post #7

Really looking forward to TypeScript support [0] as that's blocking me from using this in most of my work-related projects. Congrats to the team on 1.0! 0: https://github.com/prettier/prettier/issues/13

Yeah, that's what I thought when I saw this project for the first time today. And here I just started moving everything to typescript.

Re: Prettier 1.0

#58
post #16

I really like it for personal stuff. I'd like to hear how people are using it on teams. With some effort I got it working on save in emacs, but asking other people to please install more tooling is not always easy. I do have some authority over package.json though. How would you make it just work for everyone (using atom, vim, etc...)

Does it jump your cursor around? I'd be interested in your config if it doesn't.

Re: Prettier 1.0

#59

This is getting closer to my dream setup of being able to open files in my formatting, and saving them in the team's formatting. Formatting source code feels like a complete waste of developer time and energy, especially when they don't agree with how the team has decided to format the code. I almost wish source code files could be just serialized ASTs and that a VCS could understand them making merges etc. even easi…

I'm surprised that doesn't exist. When I did a lot of Perl in a team environment, we used perltidy. Helpful since Perl does little to encourage uniformity.

It could take any sort of style in, and produce any sort of style out. Things like K&R blocks vs Allman-style blocks, tabs vs spaces, line wrapping, cuddled/not-cuddled else, etc.

http://perltidy.sourceforge.net/stylekey.html

Edit: this looks pretty close to the same thing for JavaScript. Missing some style options, and not command line driven, but the general idea seems close: https://github.com/benjamn/recast/blob/master/README.md

Re: Prettier 1.0

#60
post #38

I'll never understand code formatters. For me the idea of my code passing through a formatter, is like if accidentally I lost part of it: there is a lot of care in the way you write your code, even in the part that the compiler does not care about: spaces. Spaces are the rhythm of the code... not sure why one would write code without rhythm and later add a synthetic one.

https://twitter.com/paulg/status/710911208849678336
Post reply on HN