I started working on JSLint 10 years ago. It started as a demonstration of a
parsing technique [http://javascript.crockford.com/tdop/tdop.html]. I intended
to then create a JavaScript engine with the compiler and other components
written in JavaScript, but the language contained so many design errors that I
could not bring myself to replicate them all.

So instead I turned the parser into a code quality tool. I thought that
syntactic analysis would be sufficient, so I pulled out the code that created
the parse tree on the theory that that would make it faster. Such thinking is
almost always wrong, as it was indeed in this case. There was no noticeable
performance improvement, and I later discovered that a tree could make JSLint
even more useful.

So I have put the tree back in. You can see the tree by clicking on the [Tree]
button. It displays the tree that was produced by the most recent [JSLint] run.
I plan to completely change the way JSLint handles line breaking and indentation
using that tree. Someday I might also use the tree to write JSMax, the inverse
of JSMin.

So at the moment, JSLint does not consider indentation or line breakage. That
will come later. The only breakage that is checked currently are the cases that
are required because of the dreaded semicolon insertion. Breaking with style is
a surprisingly difficult problem.

Three options are dropped from the new edition. option.immed and option.eqeqeq
are now always on. There have proved to be very good practices, so continuing to
make them optional is not ultimately beneficial. option.lax is no longer needed.

JSLint is now smarter about code paths, so

switch (exp) {
case 1:
if (blah) {
return null;
} else {
return undefined;
}
case 2:
x = 0;
break;

does not require a break for case 1, but it does require a break for case 2. It
is now better able to detect strange loops and other convolutions.

This is a big change. All of my code looks good on the new edition, but I
haven't tested with yours. If I broke something, please report it. Thank you.