From Jslint Is Not A Code Quality Tool For 3rd Party Code – Hugh FD Jackson:

Crockford is an opinionated, experienced and charismatic guy. As such people often do, he has gained significant influence. In this post, I’m going to focus on what Crockford thinks the role of JSLint is, as typified by this suggestion:

“There is one reliable, objective metric of JavaScript code quality that can help you in making your choice [… of library …]: JSLint. If JSLint finds problems in a library, then dump it and move on to the next one.”

I firmly believe that this attitude is damaging; and worth focusing on given his potential influence.

Yeah, wow, no. That is bad advice.

As I've said on Stack Overflow before:

As a rule, you should exempt 3rd party libraries from your linting. There's nothing you can do about external libraries unless you want to fork them and lint them yourself, which is, well, insane. ;^) And, again, minified code often takes shortcuts that aren't lint-friendly.

Lint your code before you minify to keep its quality high, but don't worry about QAing libraries you shouldn't be touching anyhow. Assume they have another method for ensuring high quality, which might include using a different linter, or a linter with a different set of rules.

I'm a huge fan of linting your JavaScript code, and there's no more thorough linter for less investment on your part than JSLint. Nothing it forces you do is objectively wrong, and you don't have to worry about getting everyone in a room to set up an ESLint rule set before you get started.

But there's absolutely no reason not to use libraries that aren't themselves lintable in their original. There's a clear interface between you and that code. It's sort of like how RMS wishes you wouldn't use any non-GNU code. A proscription from using non-JSLinted libs is more political than rational.

Labels: code, crockford, ESLint, JSLint, style