The output should be a little... prettier.

[JustinBeckwith]

I've run into a number of situations where the output of clang-format just isn't all that readable. In a lot of cases I feel like it makes the formatting of my sources worse.

It makes me a little sad to say it... but I think it's time to really consider a switch over to prettier. I'd be happy to do this work if we have general agreement, but I wanted to get the conversation started here first.

The only real debate in my mind here is if we should be strictly adhering to the Google style guide. IMO - this really doesn't matter 🤷‍♂️ I'm actually fine with whatever the default prettier config looks like. All I care about is that it's consistent :)

Thoughts? @google/google-node-team

[ofrobots]

If we think clang-format is making things objectively worse, the right thing to do would be to open a bug against clang-format first.

The think I am worried about is that – aesthetics being subjective – prettier may have some formatting issues that we might not like. This may end up being churn, and we would need some signal that 1) clang-format is not able to live up to our expectations (objectively) and 2) prettier is going to be better.

I'm sympathetic to this, but I want to make sure we have data that this is not going to be just moving furniture. We need to be sure this is an improvement.

[JustinBeckwith]

I think we have evidence in #215, #214, #156, and a variety of other issues that have come up. What sort of data do you have in mind?

[ofrobots]

Have we opened clang-format bugs for any of these issues? What's the disposition on those bugs?

[JustinBeckwith]

I have not. Do they have a github repo they monitor?

[JustinBeckwith]

Just found another one:

 * For a complete list of examples, see the [samples]
 * {@link https://github.com/googleapis/google-auth-library-nodejs/tree/master/samples}.

Is changed to:

 * For a complete list of examples, see the [samples]
 * {@link
 * https://github.com/googleapis/google-auth-library-nodejs/tree/master/samples}.

This changes the semantic meaning of the jsdoc tag and breaks our docs :(

[ofrobots]

Are you up to submitting a PR?

[JustinBeckwith]

Of course :)

[ofrobots]

To be clear: "I don't like how clang-format formats code" is not a good reason to switch formatters. What we need to demonstrate is that 1) it is not easy for JS folks to fix issues in clang-format, and 2) the existing team is not very responsive on fixing issues.

It is a given that prettier is going to be easier for JS folks to work with and fix issues in. clang-format is written in C++.

For the latter, I went and found a bug that @JustinBeckwith opened against clang-format in April that hasn't gotten looked at.

[JustinBeckwith]

Not to pile on, but my question the monitored github repo was a bit leading :) Even if they have a b/ component, that's just not going to be reasonable for any external folk that want to open a bug.

[ofrobots]

I believe this is the llvm component where clang-format bugs could also be opened: https://bugs.llvm.org/buglist.cgi?bug_status=__open__&component=Formatter&product=clang.

[43081j]

The unconfigurable styling prettier uses is very different to google's clang style so it would be nicer to keep using clang-format if the problems could be fixed.

Also see #247 which is another edge case it has trouble with.

[ofrobots]

Fixed by #259.