Static analysis tools are known to produce false positives and these false positives can “outweigh” the true positives in volume [33]. Another known fact is that, especially with larger projects, the number of warnings produced by a tool can be high, sometimes in the thousands [9].
ESLint is a static code analysis tool for identifying problematic patterns found in JavaScript code. It was created by Nicholas C. Zakas in 2013. Rules in ESLint are configurable, and customized rules can be defined and loaded.
SonarQube is our top pick for a static code analysis tool because its four editions make it suitable for all types of organizations. The Community Edition is feature-rich, including security analysis as well as bug identification and it is ideal for development environments.
UPDATED ANSWER, 2017: Yes. Use ESLint. http://eslint.org
In addition to JSLint (already mentioned in Flash Sheridan's answer) and the Closure compiler (previously mentioned in awhyte's answer) I have have also gotten a lot of benefit from running JSHint and PHP CodeSniffer. As of 2012, all four tools are free open-source and have a large and active developer community behind them. They're each a bit different (and I think, complementary) in the kinds of checks they perform:
JSLint was designed to be, and still is Douglas Crockford's personal linting tool. It ships with a great default ruleset -- Crockford's own, constantly updated as he continues to learn about JavaScript and its pitfalls. JSLint is highly opinionated and this is generally seen as a good thing. Thus there's (intentionally) a limited amount you can do to configure or disable individual rules. But this can make it tough to apply JSLint to legacy code.
JSHint is very similar to JSLint (in fact it began life as JSLint fork) but it is easier/possible to configure or disable all of JSLint's checks via command line options or via a .jshintrc
file.
I particularly like that I can tell JSHint to report all of the errors in a file, even if there are hundreds of errors. By contrast, although JSLint does have a maxerr
configuration option, it will generally bail out relatively early when attempting to process files that contain large numbers of errors.
The Closure compiler is extremely useful in that, if code won't compile with Closure, you can feel very certain said code is deeply hosed in some fundamental way. Closure compilation is possibly the closest thing that there is in the JS world to an "interpreter" syntax check like php -l
or ruby -c
Closure also warns you about potential issues such as missing parameters and undeclared or redefined variables. If you aren't seeing the warnings you expect, try increasing the warning level by invoking Closure with an option of --warning_level VERBOSE
PHP CodeSniffer can parse JavaScript as well as PHP and CSS. CodeSniffer ships with several different coding standards, (say phpcs -i
to see them) which include many useful sniffs for JavaScript code including checks against inline control structures and superfluous whitespace.
Here is a list of JavaScript sniffs available in PHP CodeSniffer as of version 1.3.6 and here is a custom ruleset that would allow you to run them all at once. Using custom rulesets, it's easy to pick and choose the rules you want to apply. And you can even write your own sniffs if you want to enforce a particular "house style" that isn't supported out of the box. Afaik CodeSniffer is the only tool of the four mentioned here that supports customization and creation of new static analysis rules. One caveat though: CodeSniffer is also the slowest-running of any of the tools mentioned.
I agree that JSLint is the best place to start. Note that JavaScript Lint is distinct from JSLint. I’d also suggest checking out JSure, which in my limited testing did better than either of them, though with some rough edges in the implementation—the Intel Mac version crashed on startup for me, though the PowerPC version ran fine even on Intel, and the Linux version ran fine as well. (The developer, Berke Durak, said he'd get back to me when this was fixed, but I haven't heard from him.)
Don’t expect as much from JavaScript static analysis as you get from a good C checker. As Durak told me, “any non-trivial analysis is very difficult due to Javascript's dynamic nature.”
(Another, even more obscure Mac-only bug, this time with JSLint’s Konfabulator widget: Dragging a BBEdit document icon onto the widget moves the document to the trash. The developer, Douglas Crockford, hadn’t tried the widget on a Mac.)
10 August 2009: Today at the Static Analysis Symposium, Simon Holm Jensen presented a paper on TAJS: Type Analyzer for JavaScript, written with Anders Møller and Peter Thiemann. The paper doesn’t mention the above tools, but Jensen told me he’d looked at some of them and wasn’t impressed. The code for TAJS should be available sometime this summer.
Google's "Closure" JS compiler produces configurable warnings and errors at compile-time. It definitely finds misspelled variables and methods, plus arity mistakes. If you're willing to write JsDoc the Closure way, it can do a lot with type information, too.
The YUI "Compressor" tool can produce warnings too, but haven't tried it yet.
I haven't had much luck with the Aptana IDE, built on Eclipse, but other people like it. See Stack Overflow discussion of JS IDEs.
The IntelliJ IDE, which isn't free last I checked, has frickin' excellent JS support. It will detect and highlight misspelled vars and methods as you type, and more. It's got autocomplete, too.
In summary, JSLint, JSHint, Plato, ESLint, Google Closure-Linter are the tools available. I faced installation issues while trying out Google Closure-Linter for Windows. But, it does mention on the web page that its support for Windows is experimental. I found and tried another tool which works well. Here is the link for it: http://esprima.org/
Also, this is the github link for the tool Esprima: https://github.com/ariya/esprima
You can see some tools for JavaScript static code analysis in this Wiki.
A tool in the Wiki, but not mentioned in this post, is DeepScan. Its focus is to find runtime errors and quality issues rather than coding conventions of linters. It covers also TypeScript, React and Vue.js.
You can try it out for your GitHub project.
I tried out ESlint and found it good..you can also add custom rules there..Here is the github repo: https://github.com/nzakas/eslint and here is the introduction to it: http://www.nczonline.net/blog/2013/07/16/introducing-eslint/
More security focused than general purpose list can be found on the Mozilla Wiki at Security/B2G/JavaScript code analysis
The purpose of this document is to collect JavaScript code analysis tools suitable for including in coming Mozilla projects or for internal use.
Also there is at least one commercial product that does security analysis: Burp gets new JavaScript analysis capabilities
The latest release of Burp includes a new engine for static analysis of JavaScript code. This enables Burp Scanner to report a range of new vulnerabilities, including:
- DOM-based XSS
- JavaScript injection
- Client-side SQL injection
- WebSocket hijacking
- Local file path manipulation
- DOM-based open redirection
- Cookie manipulation
- Ajax request header manipulation
- DOM-based denial of service
- Web message manipulation
- HTML5 storage manipulation
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With