A Prettier JavaScript Formatter • Hacker News Board

Re: A Prettier JavaScript Formatter

#51

Post by k__ » Tue, Jan 10, 2017, 6:27 PM UTC

imh wrote: post #42

tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

I don't do much serious JS. What's the problem there?

JavaScript has automatic semicolon insertion (ASI).

This will add semicolons all over your code depending on some rules, for example, if you write a return, and write the value you want to return in the next line, it adds a semicolon after the return AND after the value, effectively ignoring the value in the end.

    return
      myValue;

becomes

    return;
      myValue;

It's a bit meh, because you have to remember these rules even if you use semicolons.

Re: A Prettier JavaScript Formatter

#52

Post by artursapek » Tue, Jan 10, 2017, 6:28 PM UTC

mi_lk wrote: post #26

artursapek wrote: post #24

Earlier quoted context omitted.

Don't let HN negativity get you down. This is an awesome project and I'll contribute bug fixes/test cases if we end up adopting it on our team (very likely based on your blog post).

the parent gave an ill example and suggest a solution, how's that a negativity?

Like dangoor said, it was the way it was delivered.

Re: A Prettier JavaScript Formatter

#53

Post by mnarayan01 » Tue, Jan 10, 2017, 6:36 PM UTC

jlongster wrote: post #18

tomp wrote: post #14

Nice attempt, but currently wrong. For example, it pretty-formats this code: function makeComponent() { return /*test*/ { a: 1 }; } into function makeComponent() { return /*test*/ { a: 1 }; } From my own experience writing a formatter, comments are very difficult (if one wants to preserve them). I guess the author should reparse the generated code to ensure the AST hasn't changed.

We do. The entire Flow test suite passes when pretty-printing and re-parsing and comparing ASTs. There are a very few subtle bugs like the one you mentioned above. As noted in the readme, this is a beta. It's certainly more than an attempt.

I think what the GP is saying is to do the re-parsing before/after every time you reformat (and then presumably error exit if the ASTs don't match). When/if you no longer have any known bugs like that you might want to remove it, but it does seem like a good idea until you get there.

Re: A Prettier JavaScript Formatter

#54

Post by n42 » Tue, Jan 10, 2017, 6:46 PM UTC

dangoor wrote: post #30

mi_lk wrote: post #26

Earlier quoted context omitted.

the parent gave an ill example and suggest a solution, how's that a negativity?

I believe it was the "Nice attempt, but currently wrong." at the start of the comment. "Nice attempt" could imply that this should be thrown out in favor of another attempt to solve the problem.

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.

Re: A Prettier JavaScript Formatter

#55

Post by nailer » Tue, Jan 10, 2017, 6:56 PM UTC

This is awesome, but one request: can you please extend it into a real (ie, AST based) diffing tool? Current diffing tools all compare the text (which is basically an input format) rather than the AST, and hence end up focusing on formatting rather than actual changes.

Re: A Prettier JavaScript Formatter

#56

Post by artursapek » Tue, Jan 10, 2017, 6:58 PM UTC

n42 wrote: post #54

dangoor wrote: post #30

Earlier quoted context omitted.

I believe it was the "Nice attempt, but currently wrong." at the start of the comment. "Nice attempt" could imply that this should be thrown out in favor of another attempt to solve the problem.

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.

Classic HN :-)

Re: A Prettier JavaScript Formatter

#57

Post by ludwigvan » Tue, Jan 10, 2017, 6:59 PM UTC

For emacs, recently released rjsx-mode solves the JSX problems.

See https://github.com/felipeochoa/rjsx-mode

Re: A Prettier JavaScript Formatter

#58

Post by Dangeranger » Tue, Jan 10, 2017, 7:05 PM UTC

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.

Re: A Prettier JavaScript Formatter

#59

Post by overcast » Tue, Jan 10, 2017, 7:21 PM UTC

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.

It's almost crazy to think this already isn't just a thing. Why is this just coming to a head now, after all these years of carrying on over code formatting?

Re: A Prettier JavaScript Formatter

#60

Post by nine_k » Tue, Jan 10, 2017, 7:28 PM UTC

overcast wrote: post #59

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.

It's almost crazy to think this already isn't just a thing. Why is this just coming to a head now, after all these years of carrying on over code formatting?

I bet you heard of "go fmt".