It’d be great to have it on the JS side too. It’s a question of everyone agreeing that it’s the right one and achieving critical mass.
It’d be great to have it on the JS side too. It’s a question of everyone agreeing that it’s the right one and achieving critical mass.
This tool, to me, looks really useful for updating old javascript codebases - removing old library calls and polyfills — bringing in new native techniques.
That's go fix.
My prediction is that since this is "go-flavoured", it will face some (unwarranted) adoption resistance amongst influential JS devs. This tool might attract new devs into the code manipulation space and they'll eventually converge on to the tool with strongest community support.
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?
This program won't compile: http://play.golang.org/p/8DSev4ZjWZ
func main() { }
vs
func main() { }
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.
func main()
{
}