Investigate use of clang-format for style enforcement

[jart]

As discussed in #55, Closure Library uses clang-format to enforce style conventions and formatting in their project, since Closure Compiler linter.jar does not really do much in the way of formatting. It might be nice if Closure Rules was able to incorporate this.

Why is this important? Because Google's JavaScript and Closure style guides are by far the most difficult and onerous. Far more complicated than C++, Java, or Python style. Especially if you're used to the anarchy of non-Google JavaScript development, where style is shunned entirely in favor of succinctness. So I imagine newcomers would be rather shell-shocked by Google's style conventions at first introduction. It would be fabulous if a tool could help them.

I personally do not have the cycles to take this on. Right now I'm focused on making the features that we have, work as advertised. If others could investigate this further, it would be awesome.

CC: @hochhaus (since it won't allow me to assign directly to you)

[pcj]

I like the idea of incorporating clang-format. I also like, for example, how golang is stylistically rigid so you don't have to think about it. Similar idea with clang-format.

[kjiwa]

How about the Closure Linter: https://developers.google.com/closure/utilities/docs/linter_howto? It comes with gjslint to report errors and fixjsstyle to automatically fix them. I'm not sure if it works for ES6-style syntax.

[hochhaus]

Closure Linter is been (or is nearly?) deprecated in favor of clang-format and JSChecker / linter.jar. https://github.com/bazelbuild/rules_closure/issues/41

[jart]

Yeah we used to have a linting rule. But we took it out for this reason.

Right now we have two good proposals on the table. We would benefit from your opinion @kjiwa

1. Add Clang style checking to closure_js_library. Turn it on by default. Allow it to be disabled by saying suppress = ["style"]. If that happens, a macro wrapper around closure_js_library will ensure the Skylark rule does not link against the clang-format tool, so the user won't have to pay the price of downloading it if he doesn't use it.
2. Create a new bazelbuild/rules_style project that has a generic style checking rule for multiple languages. Design doc is here

[kjiwa]

I'm not sure I like either solution, but if I had to pick, it would be (2). Having consistently formatted code is nice, but not everybody is going to want to use clang-format (even if we'd like them to).

I noticed in a separate issue (https://github.com/bazelbuild/rules_closure/issues/99) that there is no METADATA-like mechanism available. Until something like that becomes available (if ever), I think this should be something that can be added as a presubmit hook by the developer. Perhaps the rules_style project can have example hooks for different revision control systems (e.g. git, svn).

[jart]

Thank you for chiming in. In that case it might be best if we held off on this feature for now. Right now I have a few other important features higher on my list of priorities, like a development web, as well as as a significant amount of polishing I'd like to get done first.

Clang Format is actually available in this project for the time being, for anyone who wants to whip up their own custom test rule using it. We probably won't keep it there in the long term, and it's undocumented. But the good news is there's no harm in having it there in the meantime, since users don't pay the price of downloading it if they don't use it.