My primary project at Appcelerator right now is a new tool called the Titanium Code Processor. The Code Processor is a tool for analyzing JavaScript code. It has not been released yet and is definitely still beta (maybe even alpha), but you can check it out on Github.
The goal of the code processor is to provide a generic analysis engine for performing a wide variety of analyses of interest. For example, we want to be able to detect when an application uses a deprecated Titanium API and throw a compile-time warning like most static language compilers do.
Unfortunately doing code analysis is a lot harder in JavaScript than it is in C/C++ or Java due to the dynamic nature of the language. Most JavaScript analysis tools perform static analysis; that is, they generate an Abstract Syntax Tree (AST) from the source code and walk the tree. This has the advantage of being relatively easy to implement and is also performant. The downside is that it's not very accurate because it can't accurately track relatively simple operations such as aliasing variables.
Static analysis tends to work well for most of the tasks people use it for (minification, pre-processing various JS libraries, etc.), but it's not suitable for what we want at Appcelerator. We need something much more powerful, something that doesn't currently exist, so I set out to design a fully dynamic code analysis tool from scratch.
The Titanium Code Processor is the result of this work (and work still to be completed) that consists of a custom JavaScript runtime engine with a few twists inside. I implemented a plugin system around the runtime engine for extending behavior. There are plugins that provide core functionality that is not part of the ECMAScript specification, such as require(), console() and the Titanium API itself. There are also plugins that perform various types of analysis, such as deprecated API usage detection, code coverage, platform-specific API usage validation, etc.
I'm really excited about this tool because, once completed, it will be able to do all sorts of analysis that previously wasn't possible on JavaScript code. Expect more posts on the code processor in the near future, including the rationale behind various design decisions, difficulties with the approach, etc.