Google releases its own Javascript Lint tool(closuretools.blogspot.com)
closuretools.blogspot.com
Google releases its own Javascript Lint tool
http://closuretools.blogspot.com/2010/08/introducing-closure-linter.html
15 comments
The installation instructions tell you to run "easy_install http://closure-linter.googlecode.com/files/closure_linter-la.... All well and good, but install instructions that don't reference specific version numbers freak me out. I might have gotten a little too much reproducibility religion, with all that that entails, but it seems better than being so cavalier when setting up environments.
I'm not sure what easy_install does exactly, but I guess you could replace latest with a version number. On http://code.google.com/p/closure-linter/downloads/ there's a 2.2.1 there, so instead of using "latest", you could use "2.2.1". If you care enough about this, then you probably could do some digging. Having a "latest" means they don't have to update the instructions every release, and for most people this will Just Work.
easy_install is yet another single-language package manager. It doesn't interop with the legitimate OS package manager's database of installed dependencies, and your admins probably have very little experience with it. Best to run it on one sacrificial box and then turn whatever it leaves behind into a real RPM package (or whatever your platform wants).
You can set things up so that easy_install installs into a special root. And you nearly always should.
The closest to an exception I can come up with is when you rely on image-based installs instead of package-by-package upgrades. And even then I can't manage to convince myself.
No exceptions at all for individual developers' machines.
The closest to an exception I can come up with is when you rely on image-based installs instead of package-by-package upgrades. And even then I can't manage to convince myself.
No exceptions at all for individual developers' machines.
Does anyone know how this would differ from jslint? I couldn't find anything immediately obvious.
It gives you a different set of ridiculous warnings about things that have nothing to do with your code's correctness.
Ha ha, only serious
But for real there are many warnings that pretty plainly seem to be about enforcing somebody's preferences -- gjslint wants you to write "function()" but jslint wants you to write "function ()", for example. Enforcing conventions is good, but I'm pretty sure it's orthogonal to flagging real, common problems (in javascript land, things such missing "var" or ";")
Using both and suppressing the stupid warnings doesn't seem like a bad idea, if you can take the time to get it right.
Ha ha, only serious
But for real there are many warnings that pretty plainly seem to be about enforcing somebody's preferences -- gjslint wants you to write "function()" but jslint wants you to write "function ()", for example. Enforcing conventions is good, but I'm pretty sure it's orthogonal to flagging real, common problems (in javascript land, things such missing "var" or ";")
Using both and suppressing the stupid warnings doesn't seem like a bad idea, if you can take the time to get it right.
In the example they gave, they had 9 errors. 1 was something that leads to browser incompatibility. (Trailing comma at the end of the array. IE doesn't implement the spec, Firefox does.) 1 was something that often points to logic errors. (Inconsistent indentation.) And the other 7 were someone's idea of correct style.
That said, I suspect that this lint tool will catch some issues where technically correct code can make http://code.google.com/closure/compiler/ unhappy. If you're using the Closure library, that's kind of the whole point.
That said, I suspect that this lint tool will catch some issues where technically correct code can make http://code.google.com/closure/compiler/ unhappy. If you're using the Closure library, that's kind of the whole point.
Note: It would appear the coding-style assertions can be attributed to the "--strict" flag, used in the example.
YMMV, but I get the above impression from the docs (How To) -- http://code.google.com/closure/utilities/docs/linter_howto.h...
YMMV, but I get the above impression from the docs (How To) -- http://code.google.com/closure/utilities/docs/linter_howto.h...
A very important difference for me is that jslint is not under a GPL-compatible license. jslint looks like open source, but isn't.
Closure Linter is under Apache v2, which is GPLv3 compatible.
Closure Linter is under Apache v2, which is GPLv3 compatible.
I was hoping I could run this realtime in vim, but it appears too slow on a 1000 line JS file.
Ouch, they shipped with a broken fixjsstyle command: http://groups.google.com/group/closure-linter-discuss/browse... Luckily it didn't break my jsfile, but that's kind of clumsy.
After fixing that, I ran into an even more surprising error which someone had already reported - turns out a simple JavaScript closure chokes it:
(function() {})();
http://code.google.com/p/closure-linter/issues/detail?id=3
(function() {})();
http://code.google.com/p/closure-linter/issues/detail?id=3
I remember running into this issue with their minifier at some point as well.
It fails on file I have thrown at it with some complexity other than jquery.
If any experts in Vim's makeprg/errorformat want to clean this up, that would be awesome. I just hacked it together and it seems to work well enough.