Extensioneering: Picking out the lint, and other JavaScript handling

A while ago I stumbled across a helpful Eclipse plugin called jsLex that helps with working with JavaScript within your applications, and I thought that I should mention it in case someone comes along that is interested in work with Eclipse (and Eclipse based editors) and are doing work in JavaScript. Among the features in the current release that I've found especially interesting are:
Compress/Minify/gzip multiple JavaScript
Concatenate multiple JavaScript (with the ability to specify the order of the files)

But there are a number of other features that I haven't dug into much that could be useful, such as JavaScript Profiling which allows you auto-inject profiling code into your existing JavaScript files. As I said, I've not played with it, mainly as it's not really clear exactly how to go about adding the profile code from the docs. I know that Bob is working on adding documentation for the project so I'm sure that this will be made clearer down the road.

jsLex also includes some "Cloud" functionality, but I'm not there yet, so haven't touched that portion of it at this time, maybe in the future as it seems that a lot of folks are moving in that direction.

The beta version of the plugin also adds Linting JavaScript files with JSLint. As pat on my back, I suggested this feature to Bob Buffone (the developer of jsLex) and he saw the value in it, and was able to add it pretty quickly to jsLex as part of the beta. FWIW: the site lists 1.2.2 as the beta, but the downloaded files indicate 1.2.5 as the beat.

I did run into an issue with jsLEx linting feature when installed into Aptana Studio ( 1.2.1.020234 if it matters) where the Problems panel would randomly remove entries when an entry was double clicked in the Problems panel. Bob tells me that this is Aptana specific, and I do hope that there is a workaround found within jsLex, or an update to Aptana that stops this issue from happening, as it can be annoying when you're trying to nail down some of the issues reported by JSLint. As all things beta, I expect to have a couple of issues here and there, but overall the feature is fairly robust at this point.

I have noticed that the files I've tried linting from Adobe Spry framework will choke JSLint to the point where it will stop reporting "errors". This appears to be mostly due to the coding style the Spry library was written with, not due to functionality issues. As the JSLint site says, it may hurt your feelings, so I do hope the Spry team isn't crying now. ;-)

I had a conversation with Nate Koechley from the Yahoo YUI team when I was at Adobe MAX back in November, and he says that as part of their build process, they always run JavaScript files through JSLint. Perhaps future versions of Spry will consider making JSLint happy part of the coding for future versions of Spry. I'm not religious about JSLint, by any means, but it may be worthwhile to make the effort for Spry.

Labels: compress, Eclipse, JavaScript, jsLex, JSLint, minify, Rockstarapps, Spry

3 Comments:

At February 18, 2009 4:27 PM , kinblas said...: No tears from the Spry Team.

I did a quick test with JSLint on SpryData.js and I'd say almost all of the "Problems" it was reporting were about the fact that we don't use braces for some if/for constructs. That is, we use:

if (foo)
bar = "bar";

and JSLint is expecting:

if (foo)
{
bar = "bar";
}

I didn't see an option for turning that specific error off ... but I'm not sure we want to introduce braces everywhere into the code where it isn't really necessary?

--== Kin ==--
At February 18, 2009 11:06 PM , FlipIt said...: I agree. It's kinda stupid for JSLint to flag as "error" code that uses a style many respected, professional Javascript programmers use.
At February 18, 2009 11:49 PM , Danilo Celic said...: Checking the docs for JSLint, it says that the reasoning is:
"Required Blocks

JSLint expects that if and for statements will be made with blocks {that is, with statements enclosed in braces}.

JavaScript allows an if to be written like this:

if (condition)
statement;

That form is known to contribute to mistakes in projects where many programmers are working on the same code. That is why JSLint expects the use of a block:

if (condition) {
statements;
}

Experience shows that this form is more resilient."

I don't judge code based on whether or not it used curly braces or not for single line operations, but I can tell you that I've had to add extra lines within to a single line if statement enough times that having the curly braces present makes it not only quicker but also less error prone than not having them there. But too each their own, JSLint is simply a tool, so if you use it, you should simply take it's advice and weigh it against the benefits you may get from it's advice even if you choose to follow some rules and not others, or even ignore all of the advice.