Jeremy pointed me at an article mentioning JSLint today. It’s a fantastic idea, and even more astounding, it’s actually implemented in JavaScript. This is great for showing it off as “the little language that could”.
The only problem is that it doesn’t integrate well with my development environment. I normally use TextMate or Vim. JSLint needs a JavaScript runtime, which is conveniently loaded into my browser, but inconveniently not loaded into my command line. So I set out looking for a way to come up with a command line version of JSLint.
The JSLint web site actually points out a few options. But I don’t run windows (for WSH) or Konfabulator, so that’s no good. I could try using Rhino, but I’d rather avoid a heavyweight JVM invocation (1.5s to run is too slow).
The first port of call is Mozillas spidermonkey. Handily, this is already in my FreeBSD ports collection, so it’s a quick install. But there’s one slight problem—it provides no way to do I/O. So I can’t tell it to read stdin to get the JavaScript to check. Interestingly:
- Rhino does provide a
ReadFile()
call, but not spidermonkey. How annoying. - Spidermonkey provides a File() constructor, but it doesn’t appear to compile when enabled (I think this is down to spidermonkey being disassociated from the main mozilla source tree).
So, let’s try another little hack. There’s another port available, lang/p5-JavaScript-SpiderMonkey. I should be able to use a small amount of Perl to complete the task. Except that the API is bizarre, baroque and hangs when I feed it jslint. Grrr.
On to njs. That fails to even parse the blasted fulljslint.js, stopping on the first line with an unexplained “syntax error”.
Oh well. I guess I’d better go and try to get SpiderMonkey working again.
It’s really depressing that it’s so hard to get JavaScript working outside of the browser.
Update: Ian Bicking is coming to much the same conclusions about this…