Related
Recently I've needed to write a small utility for Acrobat in its JavaScript.
Because the editor in Acrobat is pretty limited, I've installed the latest release of Eclipse IDE for JavaScript and Web Developers (Neon). It should already include the latest JSDT 2.0.
However, I've been surprised, that Eclipse's JavaScript editor does not correctly parse even simple common JavaScript patterns, like namespaces, modules, single global variable, etc. Also code folding is missing, except the very first function.
I do not expect to debug Acrobat's JavaScript code in Eclipse, but I wanted to have a smart JavaScript editor and also projects, where I could gather a few non-JavaScript resources. Some automation possibilities would be also nice, of course.
I've played with Eclipse preferences a lot and I've also searched on Internet, but I was not able to find anything really helpful.
Have I missed something in Eclipse configuration or is it really wasting of time and I should use something else?
For small projects a free IDE would be preferable, but also reasonably priced commercial products would be acceptable.
A configuration solution in Eclipse would be the most welcome, of course.
Thanks a lot for your help.
The support for newer Javascript Syntax is very bad in Eclipse (Bug).
You can use Tern.js it has a good ES5 and ES6 support.
But for Javascript development there are a lot of much better editors like Webstorm, VisualStudio, Sublime out there. You'll like more!
From my experience with Acrobat JavaScript, and the Acroforms technology (which you use when you work in PDF), there are not that many advantages you get from an IDE.
In fact, for my work (which IS extensive), a good text editor, with quote and parentheses balancing, maybe even auto-indent, and basic JavaScript code coloring is pretty much sufficient. I personally do write the scripts in BBEdit, and then copy/paste them into the Acrobat JavaScript editor window.
Keep in mind that JavaScripts in Acrobat/PDF are generally quite short, because they do not have to deal with DOM overhead, and because the field event sequence is quite structured (and it is really important to understand this sequence… more important than fancy JavaScript constructs). You also have to be aware that the JavaScript core implementation in Acrobat is relatively old (recently, they did upgrade it, but if your forms/applications are for the general public, you can't rely on them having the very newest version of Acrobat/Reader).
I have a few questions regarding JavaScript obfuscation on client side.
First question:
What is the best tool or best three tools which ones you could suggest for this operation?
Second question:
How developers should debug such code (in example with firebug) when extreme situation appears in the production if the code is obfuscated?
P.S. - I know that it's bad practice to debug in production, but we had some emergencies and experienced sometimes such situations.
Thanks for any help!
1) closure compiler with advanced optimizations
2) First double their pay, then show them jsbeautifier.org
If you are looking for obfuscation I would say JScrambler. They also have a comparison table on the site that lists other well known javascript obfuscators.
For debugging you could use something like SpiderMonkey or Rhino. Firebug is very good to retrive the decoded source code when encoding is applied.
I think IE8 javascript debugger (under the developer tools) actually re-indent/re-format your code so its readable again.
Not sure if this feature has been added to Firebug, haven't used it lately, but I really wanted this feature a while ago.
Our SD ECMAScript Obfuscator retains a map of how it obfuscated your code. If you do client-side, obfuscated-code debugging, that map will tell which symbol in the original source is it actually referencing.
If you want to debug "nicely formatted" obfuscated code, you can get that from the ECMAScript Obfuscator, by first obfuscating (getting code with all layout lost), and then running back through the obfuscator to prettyprint it (it has this option).
A third option is to generate the obfuscated code in "debugging" mode. The obfsucated result is identifcal to what the production obfuscation is, except that each scrambled variable is named "XXX". This makes understanding the code being debugged just as easy as the original, while validating that the obfuscation renaming is correct. After you've done your debugging, you simply re-obfuscate in production mode.
My team's current project involves re-writing retrieval libraries in JavaScript. We are basically looking for a setup which enables us to apply test-driven development methods.
So far we plan to use Vim to write the code, no fancy IDE. For generating output we would use Spidermonkey's shell environment. JSLint could serve as a moderate syntax checking tool.
The essential question remains: How do you develop JavaScript (browser-independent) programs?
If we are already on the right track, then maybe you can supply us with a few tips and tricks.
You can test your code in Spidermonkey or Rhino (an older JS interpreter in Java), but you won't really know which browsers it works in until you test your scripts in them!
I agree with the earlier poster, using a browser-independent library like jQuery is probably a good idea.
I have not used Spidermonkey, but I know Rhino has a good debugging GUI, allowing the usual: setting breakpoints, watches, and stepping through code.
Only testing you'll make your JavaScript code browser-independent.
If you have the chance to rewrite it all, you might consider jQuery.
It's essentially browser agnostic. Or at least it requires much less object sniffing than plain javascript.
Yes,I'm using the same environment to develop standalone JS apps (vim + SpiderMonkey). I only would add up, that I've made small in-browser IDE for reading/writing/launching JS scripts on the server-side. Sometimes it's very helpful. Also, I'm looking for using WXJavascript project, which seems to be very promising.
At the moment, the only fully supported language, and the de-facto standard for DOM tree manipulation in the browser is JavaScript. It looks like it has deep design issues that make it a minefield of bugs and security holes for the novice.
Do you know of any existent or planned initiative to introduce a better (redesigned) language of any kind (not only javascript) for DOM tree manipulation and HTTP requests in next generation browsers? If yes, what is the roadmap for its integration into, say, Firefox, and if no, for what reasons (apart of interoperability) should be JavaScript the only supported language on the browser platform?
I already used jQuery and I also read "javascript: the good parts". Indeed the suggestions are good, but what I am not able to understand is: why only javascript? On the server-side (your-favourite-os platform), we can manipulate a DOM tree with every language, even fortran. Why does the client side (the browser platform) support only javascript?
The problem with javascript is not the language itself - it's a perfectly good prototyped and dynamic language. If you come from an OO background there's a bit of a learning curve, but it's not the language's fault.
Most people assume that Javascript is like Java because it has similar syntax and a similar name, but actually it's a lot more like lisp. It's actually pretty well suited to DOM manipulation.
The real problem is that it's compiled by the browser, and that means it works in a very different way depending on the client.
Not only is the actual DOM different depending on the browser, but there's a massive difference in performance and layout.
Edit following clarification in question
Suppose multiple interpreted languages were supported - you still have the same problems. The various browsers would still be buggy and have different DOMs.
In addition you would have to have an interpreter built into the browser or somehow installed as a plug in (that you could check for before you served up the page) for each language. It took ages to get Javascript consistent.
You can't use compiled languages in the same way - then you're introducing an executable that can't easily be scrutinised for what it does. Lots of users would choose not to let it run.
OK, so what about some sort of sandbox for the compiled code? Sounds like Java Applets to me. Or ActionScript in Flash. Or C# in Silverlight.
What about some kind of IL standard? That has more potential. Develop in whatever language you want and then compile it to IL, which the browser then JITs.
Except, Javascript is kind of already that IL - just look at GWT. It lets you write programs in Java, but distribute them as HTML and JS.
Edit following further clarification in question
Javascript isn't, or rather wasn't, the only language supported by browsers: back in the Internet Explorer dark ages you could choose between Javascript or VBScript to run in IE. Technically IE didn't even run Javascript - it ran JScript (mainly to avoid having to pay Sun for the word java, Oracle still own the name Javascript).
The problem was that VBScript was proprietary to Microsoft, but also that it just wasn't very good. While Javascript was adding functionality and getting top rate debugging tools in other browsers (like FireBug) VBScript remained IE-only and pretty much un-debuggable (dev tools in IE4/5/6 were none existent). Meanwhile VBScript also expanded to become a pretty powerful scripting tool in the OS, but none of those features were available in the browser (and when they were they became massive security holes).
There are still some corporate internal applications out there that use VBScript (and some rely on those security holes), and they're still running IE7 (they only stopped IE6 because MS finally killed it off).
Getting Javascript to it's current state has been a nightmare and has taken 20 years. It still doesn't have consistent support, with language features (specified in 1999) still missing from some browsers and lots of shims being required.
Adding an alternate language for interpreting in browsers faces two major problems:
Getting all the browser vendors to implement the new language standard - something they still haven't managed for Javascript in 20 years.
A second language potentially dilutes the support you already have, allowing (for instance) IE to have second rate Javascript support but great VBScript (again). I really don't want to be writing code in different languages for different browsers.
It should be noted that Javascript isn't 'finished' - it's still evolving to become better in new browsers. The latest version is years ahead of of the browsers' implementations and they're working on the next one.
Compile to Javascript
For now, using a language which compiles to Javascript seems to be the only realistic way to reach all the platforms while writing smarter code, and this will likely remain the case for a long time. With any new offering, there will always be some reason why one or more vendors will not rush to ship it.
(But I don't really think this is a problem. Javascript has been nicely optimized by now. Machine code is also unsafe if written by hand, but works fine as a compile target and execution language.)
So many options
There is an ever growing pool of languages that compile to Javascript. A fairly comprehensive list can be found here:
List of languages that compile to JS on the Coffeescript Wiki
Noteworthy
I will mention a few I think are noteworthy (while no doubt neglecting some gems which I am unaware of):
Spider appeared in 2016. It claims to take the best ideas of Go, Swift, Python, C# and CoffeeScript. It isn't typesafe, but it does have some minor safety features.
Elm: Haskell may be the smartest language of them all, and Elm is a variant of Haskell for Javascript. It is highly type-aware and concise, and offers Functional Reactive Programming as a neat alternative to reactive templates or MVC spaghetti. But it may be quite a shock for procedural programmers.
Google's Go is aimed at conciseness, simplicity, and safety. Go code can be compiled into Javascript by GopherJS.
Dart was Google's later attempt to replace Javascript. It offers interfaces and abstract classes through a C/Java-like syntax with optional typing.
Haxe is like Flash's ActionScript, but it can target multiple languages so your code can be re-used in Java, C, Flash, PHP and Javascript programs. It offers type-safe and dynamic objects.
Opalang adds syntactic sugar to Javascript to provide direct database access, smart continuations, type-checking and assist with client/server separation. (Tied to NodeJS and MongoDB.)
GorillaScript, "a compile-to-JavaScript language designed to empower the user while attempting to prevent some common errors." is akin to Coffeescript but more comprehensive, providing a bunch of extra features to increase safety and reduce repetitive boilerplate patterns.
LiteScript falls somewhere inbetween Coffeescript and GorillaScript. It offers async/yield syntax for "inline" callbacks, and checking for variable typos.
Microsoft's TypeScript is a small superset of Javascript that lets you place type-restrictions on function arguments, which might catch a few bugs. Similarly BetterJS allows you to apply restrictions, but in pure Javascript, either by adding extra calls or by specifying types in JSDoc comments. And now Facebook has offered Flow which additionally performs type inference.
LiveScript is a spin-off from Coffeescript that was popular for its brevity but does not look very readable to me. Probably not the best for teams.
How to choose?
When choosing an alternative language, there are some factors to consider:
If other developers join your project in future, how long will it take them to get up to speed and learn this language, or what are the chances they know it already?
Does the language have too few features (code will still be full of boilerplate) or too many features (it will take a long time to master, and until then some valid code may be undecipherable)?
Does it have the features you need for your project? (Does your project need type-checking and interfaces? Does it need smart continuations to avoid nested callback hell? Is there a lot of reactivity? Might it need to target other environments in future?)
The future...
Jeff Walker has written a thought-provoking series of blog posts about "the Javascript problem", including why he thinks neither TypeScript, nor Dart nor Coffeescript offer adequate solutions. He suggests some desirable features for an improved language in the conclusion.
should be JavaScript the only supported language on the browser platform ?
Yes and no. There is an alternative out there called Dart by Google which does compile to JavaScript and just like jQuery it tries to make DOM manipulation a bit easier. It may be fun to experiment, check it out.
From Google see The dart language
From Microsoft see TypeScript language
See also
Elm
Kal
It is true that Javascript was at one point notoriously hard to deal with but the web development community has come a long way since. Instead, I would encourage you to have a look at jQuery. It's easy and abstracts away all the various problems.
And there really are no alternatives that work across the board. Flash comes to mind but that too is ECMA script and it's probably over kill for most things.
Short term, I'd use things like jQuery to hide the browser incompatibilities. Long term, technologies like Silverlight or Adobe AIR may make this a very different minefield (but still a minefield) in the future.
Doug Crockford gave a talk to Google detailing the bad and good parts of JavaScript and its future. It actually hasn't changed much at all since 1999--which can be said to be a good thing (pretty much all browsers can run the same code as long as you're aware of their limitations) and Doug shows where the good parts were mostly misunderstandings that turn out to be very powerful.
For DOM manipuluation, look at JQuery as a client-side library that replaces most of the awful DOM API with operations that are a pain to write to pretty elegant bits of code that are easier to write.
If you're thinking that JavaScript has deep issues, I recommend Doug Crockford's book, JavaScript: The Good Parts. (Or Google for "Crockford JavaScript" to find several video presentations he's done.) Crockford sketches out a safe subset and set of practices, and specifically lists some parts of the language to avoid.
I'm unaware of plans to replace JavaScript as the de facto means of manipulating the DOM. So best learn to use it safely and well.
In terms of client side Javascript is the only way to manipulate the DOM. In terms of server side there are a multitude of ways.
Internet Explorer supports pluggable scripting languages, although the only one reliably included with IE besides JScript is VBScript.
As far as I have seen, there seems to be a general sort of bias toward dynamic languages in the browser, and JavaScript seems to fill this need adequately enough that network effects make any other language a non-starter. The language is actually quite powerful, though its implementation in browsers leaves much to be desired.
If you're willing to restrict your customers/visitors to specific browsers, and possibly willing to require them to install a plug-in, you could look at MS Silverlight -- a readable overview is on wikipedia. With Silverlight 2, you can run, client-side, code you've written in C#, IronPython, IronRuby, VB.NET, etc; the free Moonlight clone of Silverlight, from the Mono project, promises to bring the same functionality to Linux.
In practice, most developers of web apps and sites prefer to reach wider audiences than Silverlight (and eventually Moonlight) can currently deliver -- which means sticking with Javascript, or possibly Flash (which uses a similar programming language, Actionscript).
So, gaining substantial mindshare, adoption and traction for anything else is proving to be an uphill fight even for Microsoft with its large groups of engineers and marketing budgets and a free-software project on the side (to possibly ease worries about proprietary lock-in) -- which may help explain why there's very little interest, e.g. on the part of the Mozilla Foundation, in pushing towards such a goal. "Apart from interoperability", you say: but clearly the issue of interoperability is THE biggie here, given what we observe wrt Silverlight's progress...
As already said, you have Flash (ActionScript, which is a derived language from Javascript) and Silverlight/Moonlight (IronPython, IronRuby, JScript, VBScript, C#) that can run in the browser via plugins (the first one being much more ubiquitous).
There is also another alternative if you like Ruby: HotRuby, it's a ruby implementation in javascript that will run in the browser. It is not very mature yet, but you can have a look at it.
One thing I haven't seen mentioned (oh, I see Alcides mentioned HotRuby while I was writing and Nosredna mentioned GWT and Script#) and would like to throw out there is there are a number of implementations of [insert language]-on-JavaScript (eg. translators that allow you to convert Ruby, Python, C#, Java, Obj-J/Cappuccino [similar to Obj-C/Cocoa] or Processing [for Canvas] to JavaScript either on the client or before deployment [and some of which also feature various abstraction libraries]). Of course there's a performance overhead if it is being translated on the client, but if you are more comfortable with another language it will allow you some flexibility.
Personally, though, I recommend learning to love JavaScript. It's an excellent, powerful language, and pretty elegant once you get to know it. I'm facing the opposite dilemma, chomping at the bit to have a capable server-side JavaScript/DOM solution that meets all of my needs. /unsolicited opinion
JavaScript is the English language of the web. English historically spread because it had a strong navy conquering various countries. This is comparable to big companies that conquered the web with JavaScript. It's a language clobbered together from multiple European sources (Greek, Latin, Germanic languages, French even some Chinese and Indian words). JavaScript borrowed a lot of concepts throughout the years from other languages (structural, OO, functional). English is spoken in different places with slight variations in dialect and accent, that can render understanding difficult. Just like JavaScript has different browsers interpreting it a bit differently.
Even though English is easy to learn initially, it has very inconsistent pronunciation and more exceptions than rules. Just like JavaScript it's always there to offer a surprise.
Despite the different accents, JavaScript is the lingua franca of the web. Just like you might not be English and write here in English, every web browser has a certain degree of English understanding. IE6 is like the guy who says on his resume that he's fluent, but only went to a two week course on English as a foreign language.
There have been attempts to supplant English as the worlds main language, e.g. Esperanto. But all of them failed, because most people on earth speak some English. In the same way it will be difficult to introduce better alternatives to JavaScript.
Jquery (still javascript but) it will really help you they have support for almost all the browsers and it isn't really that hard to learn :)
No. JavaScript is it, but it will evolve. The next version is "JavaScript Harmony," and you can learn more if you Google that.
Now and then someone suggests putting a byte code interpreter into the browsers alongside JavaScript. Probably won't happen, at least for awhile.
I happen to love JavaScript. But there are other solutions, including GWT, which compiles Java to JavaScript and Script#, which compiles C# to JavaScript.
I don't think Javascript will be replaced any time soon. For a completely different approach to rich clients, you might want to investigate Flex, which is a Flash-based technology.
Maybe something like haxe (see haxe.org) could help you. It is a language which seems cleaner than JavaScript and can be compiled down to JavaScript, so it can be run inside a browser.
I know that this is not a direct answer to your question, but I thought it might be interesting for you, nevertheless.
Many people understand that Javascript isn't best and prettiest language ever. However, it is currently supported by browsers, and thus it will be extremely hard to introduce a different language. We simply don't need another browser war.
This explains why I know of no plans of switching to a different client-side language.
But I think Javascript isn't so bad if you start thinking about DOM model and how would one work with it. Many things that are messy with JS are the result of the way DOM model works.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
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?
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.
http://jsanalyse.codeplex.com/
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.