Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Prettier JavaScript Formatter

jlongster.com

Post reply on HN
Print view View original

91–100 of 159 posts

Re: A Prettier JavaScript Formatter

#91

Post by joshwcomeau »

BrandonM wrote: post #88

If I personally prefer the second Promise chain: myPromise.then(() => { // ... }).then(() => { // ... }).catch(() => { // .. }); and if I also prefer the Lisp-like approach and hate putting: ); on its own line, am I part of the problem? What if my whole team uses that style? For example, we would write: foo( reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne() ); as: foo(reallyL…

I think that this is definitely not a tool for everybody, and I think that's alright.

Dan Abramov said it best, when he opened an issue urging to resist the urge to add configuration: https://github.com/jlongster/prettier/issues/40

Configuration has a cost, and the product will be better and more reliable if it's limited. As it stands right now, the configuration isn't ideal for my preferences, but I'm fine with that; either I'll

* use the tool and adopt new patterns (ones which, frankly, have very little impact on anything), * keep doing this stuff manually (it's gotten me this far!) * fork the project, and bear the cost of maintaining the updated configuration myself.

Re: A Prettier JavaScript Formatter

#92

Post by SomeCallMeTim »

esbenp wrote: post #75
SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

https://github.com/esbenp/prettier-vscode

Awesome that this exists already. Now we just need TypeScript support... :)

Re: A Prettier JavaScript Formatter

#93

Post by robbrown451 »

Would it be reasonable to have an editor that ran this every time you resize your editor window?

I like to have multiple windows on screen at once, and will often adjust them to make best use of screen real estate. I tend let it soft-wrap the text, but I'd love it if it would do soft-wrapping... prettier.

Re: A Prettier JavaScript Formatter

#95

Post by softawre »

zem wrote: post #68
Dangeranger wrote: post #58

After using Elm and the elm-format package in Emacs for the last few weeks I can say that not having to format the source and just letting your editor do it for you on save or via a command is so very nice. This is a trend that I feel is going to catch on across any language that can support it. It makes trivial decisions and arguments about formatting a thing of the past.

i hate the output of elm-format, though :( it's very wasteful of vertical space.

And this is why we have yet to converge. We are people, we have opinions! And some of us lead teams and make decisions.

Re: A Prettier JavaScript Formatter

#96

Post by softawre »

tomp wrote: post #78
n42 wrote: post #54

Earlier quoted context omitted.

The entire comment was patronizing. "Nice attempt" minimizes the effort involved and implies the author is a novice. "but currently wrong" categorizes the entire project as a failure because of a single bug. The followup "From my own experience writing a formatter" really drives the whole thing home.

Wasn't meant that way.

"Nice attempt" used to actually mean the words it said. You know, like "nice job".

Re: A Prettier JavaScript Formatter

#97

Post by SomeCallMeTim »

evmar wrote: post #34
SomeCallMeTim wrote: post #29

Flow is cool, but TypeScript has way more traction. Would jump on this in an instant if it had TypeScript support and a VS Code plugin.

clang-format supports TypeScript and has a VS Code plugin. (See my other comment in this thread for some discussion of the differences between the tools.)

I may need to check that out. Thanks for the link!

Re: A Prettier JavaScript Formatter

#98

Post by korm »

munificent wrote: post #71
sharpercoder wrote: post #5

> If computers are good at anything, they are good at parsing code and analyzing it. So I set out to make this work, and prettier was born. I didn't want to start from scratch, so it's a fork of recast's printer with the internals rewritten to use Wadler's algorithm from "A prettier printer". Bob Nystrom (munificent) disagrees[0] after writing one himself: > The search space we have to cover is exponentially large, a…

I will note that one could design a pretty printer that reliably had better performance if the formatting style they chose was simpler and more amenable to it. My (mostly self-imposed) task was more difficult because I was trying to follow the existing style that humans were hand-applying to their Dart code, and that had a lot of tricky non-local cases that look nice but are hard to automate.

I have to say Dartfmt is one of my favorite things about using Dart. It works amazingly well and the fact that it's not configurable is a great decision [0]. I'm never afraid to peek into unfamiliar code because of that. So thank you.

[0] https://github.com/dart-lang/dart_style/wiki/FAQ#why-cant-i-...

Re: A Prettier JavaScript Formatter

#99

Post by hokkos »

rhengles wrote: post #7

Much better than "Standard JS" and its choice of no semicolons. I know about "Semi Standard JS", but I refuse to accept such a little difference that could be a configuration has to live in a entirely new project.

I hate that they had the audacity to call it standard.

Re: A Prettier JavaScript Formatter

#100

Post by david-given »

zem wrote: post #68
Dangeranger wrote: post #58

After using Elm and the elm-format package in Emacs for the last few weeks I can say that not having to format the source and just letting your editor do it for you on save or via a command is so very nice. This is a trend that I feel is going to catch on across any language that can support it. It makes trivial decisions and arguments about formatting a thing of the past.

i hate the output of elm-format, though :( it's very wasteful of vertical space.

Tangential question:

Why do Haskell and Elm format lists like this?

    type alias Circle =
        { x : Float
        , y : Float
        , radius : Float
        }
...and not like this:

    type alias Circle = {
      x : Float,
      y : Float,
      radius : Float
    }
...? The first makes me shudder with revulsion every time I see it --- that's not where commas go, dammit --- and there must be a reason, which I've never been able to figure out.

The Elm style guide mentions in passing that trailing commas require a diff that adds a field to modify two lines but one, but that applies to leading commas too if you add the field at the beginning of the list.

Post reply on HN