jQuery Lint is a simple script you can download and use with jQuery. It works over the top of jQuery and diligently reports errors and any incorrect usage of jQuery. It will also, to some extent, offer guidance on best practices and performance concerns.
Unlike JSLint, jQuery Lint is a runtime reporter. To use it, you need to include it, after jQuery, in your document:
<script src="jquery.js"></script> <script src="jquery.lint.js"></script>
jQuery lint’s main objective is to notify you of incorrect usages of jQuery’s API. So, if you pass incorrect arguments to any method then jQuery Lint will let you know. It compares your arguments to the argument signatures in jQuery’s API. It reports via Firebug, although you can quite easily plug-in your own console mechanism.
It has four different error-reporting levels (accessible via jQuery.LINT.level), zero reports nothing, three will report everything, including small things like using css().css().css() instead of css({...}). It’s quite configurable too. You can add your own checks. E.g.
jQuery.LINT.special[1].jQuery = jQuery.LINT.special[1].jQuery || []; // Add check on error-reporting level one. // Check jQuery method. jQuery.LINT.special[1].jQuery.push(function(selector, context) { if (selector === '*') { return "Don't use the universal selector!"; } });
jQuery Lint tries to help you in determining where the problem occurred in your code. It’s not much help to you if it just says, “Err, you called css() incorrectly!”. If it occurred as a result of an event then Lint will say so, and if you’re using a browser that provides a stack-trace as part of its Error object (like Firefox) then Lint will also provide you with the file-name and line number. E.g.

You can read more about jQuery Lint and download it at Github:
The idea of a lint-like script for jQuery has been floating around for some time. I want to thank Dave Methvin in particular, for it was his idea that sparked my interest originally.
This is quite a young project, so there will be bugs. Please report them!
good stuff, thanks mate
Awesome! That is definitely an elegant way to implement it. Did you pull the API signatures from the new documentation site?
@Dave, yep, I had to JSON’ify
api.jquery.com/apiusing YQL. Then I filtered the result to take out all the stuff I didn’t need, like descriptions and examples. Then I was left with just the name, types, version and argument signatures. There were still a few corrections that it required, but it seems to work pretty well.Great, just what I needed!
Great idea! This is saved in my resources folder right along with the jQuery library. I can’t wait to implement this on my next project!
Cheers
Is this aware of 1.3/1.4 differences? If so, this seems like it would be awesome to just include on a development site that has switched to 1.4 before making the crossover to the live production site.
The backwards incompatibilities aren’t too hefty at all though, all in all.
nice one, thanks… is there any way of excluding selected files? some of the 3rd party scripts i use are throwing up lots of junk.
Very clever, now please work on an API to quirkmodes so I can do cross-browser JS/CSS compatibility testing on one machine, thanks
Can we just include it by URL from github like we do the regular jquery library from Google’s CDN?
I’m sure its easy to test…but is there any drawback to doing that here other than better performance with a local file? Seems like if we’re only using it in test mode, it should be fine..
Let me know!
Thanks. Brilliant idea!
I’ve added jQuery Lint to the “default” dependencies in jQuery 1.4.0 demo: on http://jsfiddle.net/zalun/UYpSE/
I will watch this project closely and update the lib often.
@Nick F, yep, it has been designed to work in 1.3.2 and 1.4. The api data included in it should be able to accommodate older versions too, although I haven’t tested any.
@Jono, Not at the moment. I’ll try to build in a way of doing that, some time in the future.
@tresstylez, yep, you can include it directly from Github. It doesn’t really matter.
@Piotr, Thanks! JS Fiddle is awesome!
I’ve modified the JQuerify bookmarklet to also load JSLint…..
I can see both js files loaded correctly in the HEAD, but when I try an invalid jQuery call ( jQuery(‘a’).css() ),it appears to only show me the standard Firebug error in the console.
Any ideas?
@tresstylez, Can I see the code? The problem may be that jQuery Lint is being loaded slightly before jQuery itself, in which case jQuery Lint silently “fails” — does nothing.
Sure, code is here:
http://pastebin.me/5159a21863df4c307ac536660222db2e
Made the bookmarklet by using Crunchinator from the post above..
http://ted.mielczarek.org/code/mozilla/bookmarklet.html
Let me know if you see anything. I basically just made a 2nd function called ‘getLint’ that loads your JS in the head. Everything else is the same, and like I said I see both loaded in the page, so its working.
Maybe I’m not triggering it correctly?
This one seems nice, though I would like to have some more information:
1.
No elements were found with the selector: "th" jquery.lint.js (rad 32)It doesn’t tell me in what context this is relevant (I’m not interested in what line in jquery.lint.js this happened)
2.
jQuery(...) special check failed jquery.lint.js (rad 32)Again, row 32 of lint isn’t much of use, though this time it actuall has an location. But it contains a bit too much data:
First there is 3-4 entries of jquery.js (why the first two is on one line is beyond me), whom which are rather irrelevant as we are not testing jquery by it self, but my own code. Second I would like to be able to click on the relevant line to inspect relevant line.
@tresstylez, it works for me. Just a thought — maybe the call to
getLintshould be within the callback of `getScript`, when you request jQuery… that way, it’s requested when jQuery has finished loading.@Carl, thanks for your comment. The line number and file on the right-hand side of each log is not configurable — I have no control over how Firebug handles that. And it’s the same deal with your second point, I have no control over those line numbers/files. I know you’re not interested in the errors thrown from jQuery itself but Lint has no way of knowing what file contains what, so it would be foolish to remove any of those possible locations. It’s pretty clear that you should be paying attention to line 20 of
filemanageranyway.You can use ScriptCanary to capture errors that your users are hitting, including non-JQuery Javascript.
http://goldcreekgroup.blogspot.com/2009/12/how-to-capture-javascript-errors.html
Hi James,
this is a really exciting project. You say it’s a runtime reporter, could you elaborate on how it works? I would be interested in including something like this in my CI build, but it would need to be more of a JSLint style parser for jQuery rather than runtime application so I could maybe run it through rhino and env.js. I can maybe help you do this if needed.
Also it would be great to create/document a formal set of rules to validate against, have you got this anywhere?
Hi,
I visit GitHub but I don’t see the jquery.lint.js file to download
please advise, I want to try it.
thanks
Hi James,
Great project! I’ve been using it to review my next jPlayer plugin release and Lint pointed out a number of improvements.
One thing though, Lint appears to report the use of .offset() as a warning relating to the use of $.boxModel, which was deprecated in jQuery 1.3. After reviewing, .offset() was rewritten from scratch in jQuery 1.3 to increase performance and they added new features in jQuery 1.4. The $.boxModel was indeed deprecated in jQuery 1.3, but I do not use it anywhere in my code and wonder why I get this warning from Lint.
Cheers.
Hi James,
After further testing, the problem reported above with .offset() happens when jQuery 1.3 is used. When I switched to jQuery 1.4 the warning disappeared.
Another issue I noted in jQuery 1.3 with Lint was the message:
No elements were found with the selector: “*” jquery.lint.js (line 32)
This message gave no other details, such as the location of the warning, and it too disappeared when switching to jQuery 1.4.
Cheers.
Very cool! Is there a way (if not now then in the future) to provide a configuration option where I can pass a list of plugin files to ignore? I’d love to be able to have it throw all warnings for “our” code, but ignore warnings in the 3rd party plugins. As it stands now, since our app uses quite a few plugins, my console is littered with warnings and I have to expand each to see which ones point to code we have written.
Again though, very cool, thank you!
Jim
Perhaps, if possible, a warning could be added if trying to call
$(obj).offset({left: X, top: Y })on an out of DOM object, as this isn’t fully supported/possible.