JSLint-Feature – Error Severity

Hi Douglas,
I have been to a good number of your talks, and I love the idea behind JSLint. I even don’t mind it when JSLint makes me cry every now and then, however, I feel like the priority of JSLint should be around launch successful code early and often.

Here at Kabam we build games that run as HMTL5 apps, and recently we have started to use JSLint as part of our build process. In a few cases it has caught some minor errors and we were later able to resolve them.

Our build process uses Jenkins, which is an open source version of Hanson. These continuous build automation tools make use of another wrapper library you might be familiar with. http://code.google.com/p/jslint4java/

So in this sense let’s say a develop wants to add a new piece of code, and this code causes a problem.

JSLint reacts in the following ways,
– it has a an error limit and stops reporting erros after a certain amount
– errors are not prioritized based on ‘newness’ – because that would be hard
– errors are not prioritized based on priority.

The end result is that a team must fix all errors to get the maximum value out of JSLint.

I propose a 2 part solution.
1. JSLint should not set error priority, unless it sets sensible defaults
2. JSLint should report an error code so that a wrapper like jslint4java could use a config file set an error priority.

This would allow teams to triage error types as part of their build/ development process.

On line 1326 you have a function warn() defined I propose it’s written something like so, including a new warning property, defining an error.type property using the bundle[] accessor name as the error code.

If you think of some other change that could get to the spirit of what I am looking for that would be great too. If I get the time I might try to implement a prototype. Hudson and Jenkins have 3 levels of errors, High, Medium, and Low.

Would you have some suggestions as to what would make good defaults for each of the error.types?

I feel like this change would better support agile development and continuous integration, and would allow teams to prioritize their development efforts.

Thank you for being a beacon and leader in the community.

function warn(message, offender, a, b, c, d) {

        var character, line, warning;

        offender  = offender || next_token;  // `~
        line      = offender.line || 0;
        character = offender.from || 0;

        warning = {
            id: '(error)',
            raw: bundle[message] || message,
            type: message,
            evidence: lines[line - 1] || '',
            line: line,
            character: character,
            a: a || (offender.id === '(number)'
                ? String(offender.number)
                : offender.string),
            b: b,
            c: c,
            d: d

        warning.reason = warning.raw.supplant(warning);


        if (option.passfail) {
            quit(bundle.stopping, line, character);

        warnings += 1;

        if (warnings >= option.maxerr) {
            quit(bundle.too_many, line, character);

        return warning;

Comments are closed.

Post Navigation