It actually isn't a compiler error in Go to deviate from gofmt's specification* but it is a widely enforced rule in the community. Most major Go projects use gofmt and any Go code, such as the built-in libraries, are gofmt'ed. You're fighting against the tide if you format otherwise.
Given that, jsfmt doesn't need 100% adoption: using it in a single project or library would still be useful. Stating new contributions must be jsfmt'ed would be less trouble than most standard pull request requirements (pass + update any relevant testing code, ...).
I personally love these formatting tools and am looking forward to more of them, such as ClangFormat[1].
* You might be thinking of unused variables or imports resulting in compiler errors, which isn't the same as not compiling due to formatting?
which produces the error "prog.go:4: syntax error: unexpected semicolon or newline before {". As I understand it this is because of the rules of where it will insert semicolons. It isn't enforcing everything about the format which is why I said "to a degree" but it is still one of the most opinionated compilers on format that I know of.
Either way, I'm glad they did it. The "where should the curly brace go" is one of the most annoying bike-sheds.
Given that, jsfmt doesn't need 100% adoption: using it in a single project or library would still be useful. Stating new contributions must be jsfmt'ed would be less trouble than most standard pull request requirements (pass + update any relevant testing code, ...).
I personally love these formatting tools and am looking forward to more of them, such as ClangFormat[1].
* You might be thinking of unused variables or imports resulting in compiler errors, which isn't the same as not compiling due to formatting?
[1]: http://clang.llvm.org/docs/ClangFormat.html