I'm used to having my compiler complain when I do something stupid like a typo on a variable name but JavaScript has a habit of letting this pass.
Are there any static analysis tools for JavaScript?
I'm used to having my compiler complain when I do something stupid like a typo on a variable name but JavaScript has a habit of letting this pass.
Are there any static analysis tools for JavaScript?
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.
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
In the commercial realm, Coverity Static Analysis supports analysis of JavaScript as of version 7.7 (mid-2015). Regarding your specific inquiry about typos, my pet project appearing in the latest release (8.0, beginning of 2016) does find typos in names of program elements.
As a key developer on the project, please accept my shameless plug: Though not yet as mature as the venerated C/C++ analysis, Coverity's JavaScript analysis shares much of the same engine, with the same focus on finding high-value defects with a low rate of false positive defect reports. We are increasing our focus on finding security defects in JavaScript (and other languages), in addition to finding general programming errors.
Now, here are some typos it finds (exact typo left as an exercise for the reader, to emphasize how easily these can be overlooked):
merge.js: (stable link) (latest revision)
commands-packages-query.js: (stable link) (latest revision)
series-pie-tests.js: (stable link) (latest revision)
outline_case.js: (stable link) (latest revision)
I like Jslint for this sort of thing...
Flow does static analysis with and without annotations.
If you need annotations, the syntax is compatible to TypeScript.
Install the package with :
npm install --global flow-bin
There's also some tooling. Have a look at gulp-flowtype and perhaps SublimeLinter-flow
JSAnalyse has just been published on codeplex. It is a tool which analyses the dependencies between javascript files. You can even define the allowed dependencies and JSAnalysis checks whether the defined rules are fulfilled or not. That allows to keep track about the javascript dependencies even in big projects and have a clean architecture.
JSAnalyse can be executed as a command line tool or configured via the Visual Studio Layer Diagramm. It is also easy to integrate into the build. With gated check-ins you can keep the dependencies under control.
Our SD ECMAScript CloneDR is a tool for finding exact and near-miss copies of duplicated code across large JavaScript source code bases.
It uses the language syntax to guide the detection, so it will find clones in spite of format changes, inserted/deleted comments, renamed variables and even some inserted/deleted statements.
The site has a sample CloneDR run on Google's Closure library.
Full disclosure, I'm behind this: http://www.toptensoftware.com/minime which does minification, obfuscation and a reasonable set of lint style checks.
© 2022 - 2024 — McMap. All rights reserved.