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.

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?

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 :-)

Wasn't meant that way.

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

Also, “currently wrong” is a really sweeping statement to make based on a single problem written in a fairly uncommon style. Yes, there are things which need to be fixed but that doesn't mean we have to be so dismissive of someone else's work which they've given away for free to the community.

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

I'm actually very excited by your "attempt". Looking forward to where it goes!

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.

Running existing codebases through it and comparing the ASTs is a nice idea. Seems like it should be pretty easy to automated it for the top N (100?) JavaScript projects.

While understanding the state of a project is important for potential adopters, might I suggest filing a GitHub issue in lieu of this comment as something that might actually have a positive outcome?

I've found another issue where it just removes comments entirely inside an otherwise empty block.

    function doSomething() : int {
      return myPromise
      .then(() => {
        // ...do thing
        /* what */
      })
      .catch(() => {
        // ..do other thing
        /* the heck */
      });
    }

becomes

    function doSomething(): int {
      return myPromise
        .then(() => {})
        .catch(() => {});
    }

Still a very nice pretty printer, though.

I used Recast on a codebase at work to migrate to a new code style, and I ran into a long tail of issues with preserving comments that looked like they would require some significant work to fix. I know the author of Recast (Hi Ben) and corresponded with him a little bit about it at the time.

It also is not preserving JSX spacing correctly, and the example the site provides even shows that:

    JSX is<strong>supported</strong>

Note the lack of space after the word "is".

I know this isn't really practical, but as a rule you shouldn't mix comments and code. Comments should be above any function definitions for this and many other obvious reasons. Removing inline comments seems like a reasonable default for a project like this, since those adopting it have already ceded some amount of control over the way their code is structured.

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.

The first one returns an object, the second one returns undefined