-
Notifications
You must be signed in to change notification settings - Fork 11
Frequently Asked Questions
JSLint.NET was born from the JSLint4VS project. The core concepts behind that tool are excellent; using the V8 engine to run JSLint over your JavaScript and reporting the errors. But the implementation is highly coupled to Visual Studio and isn't well suited for standalone use in .NET.
Also, with the original core developers tied up on other projects, the libraries distributed with JSLint4VS have fallen behind. For example, HTML and CSS parsing has been cut from JSLint for some time, but is still present in JSLint4VS.
So the decision was made to take the best parts from JSLint4VS, cut the parts that no longer make sense, and rebuild it under a new, more future proof name - JSLint.NET.
The decision was made very early on to stick to the tool's namesake - JSLint.
If JSHint is your linter of choice, Mads Kristensen's Web Essentials includes a thorough implementation. In fact, it's a highly recommended tool even if you don't use JSHint (it's an optional feature).
Absolutely. Ignoring third-party libraries or generated code is a common scenario and well supported. However, rather than storing the skipped paths in a Visual Studio project file, they're stored in a new JSON settings file that can be easily shared and re-used with other tools in the JSLint.NET family. See the JSLint.NET Settings page for more information.
The short answer is no, that isn't supported. The //ignore jslint feature from JSlint4VS has been cut.
Experience has shown that the ability for developers to ignore anything becomes very problematic in large teams. The value of a code quality tool like JSLint comes from having the discipline to trust its advice - it's there to help. If finding ways to avoid that advice is desirable, then the point of the tool has been missed.
As a rule, JSLint.NET will not add anything - such as custom avoidance - on top of the JSLint API.
One of the goals of JSLint.NET is to be as complete, accurate and up-to-date as possible. However, there are a couple of exceptions.
The first omission is the "tokens" object tree normally available in JSLINT.data(). Because it includes cyclic references, it's not possible to JSON serialize this information and transmit it to .NET in the same way as the rest of the data. For now, it has been cut.
The second change is the "null stop". JSLint adds a null entry to the end of the errors array to signify that a stopping error was found; for example when the maximum is reached or a serious syntax problem is encountered.
Persisting this null on the .NET side can cause unexpected runtime errors. It has been replaced with the HasStoppingError property, which represents the spirit of the null stop in a way that is less problematic for .NET.