Zero setup bug finding machine

The JavaScript Studio web app now features a UI to use the script analyzer without any setup.

If you haven’t heard about JavaScript Studio before, it’s a cloud service that finds runtime errors with dynamic analysis and speculative branch execution. It can execute API functions and trigger events without knowing any arguments. It doesn’t require test data or any script modifications.

Since the public beta release the analyzer has improved a lot under the hood. It now passes the ES5 related tests of the official ECMA262 test suite and can dig deeper into scripts than before.

Use the analyzer without any setup

If you logged in on javascript.studio since last week, you’ve noticed a new interface to run the analyzer directly on the web page. You can copy any ES5 script into the form, specify an optional entry point and hit „Analyze“ to receive an error report in a few seconds. Here’s a simple example:

document.body.addEventListener('click', function (event) {
event.stopPropagations()
})

This demonstrates how the analyzer finds a typo. A click on „Analyze“ shows this report:

Notice that no manual instructions are required to trigger the event execution. The call tree shows the click event that triggered the function invocation.

Let’s look at something a little more interesting:

'use strict'
var arr = []
window.map = {
  add: function (prop, value) {
arr[prop] = value
},
  remove: function (prop) {
if (arr.hasOwnProperty(prop))
delete arr[prop]
}
}

This looks fine, right? It turns out there is a strict mode edge case that causes a runtime error. If you run the above script with map as the entry point, it yields this report:

The fix here would be to use {} instead of [] as the internal store.

We have to specify map as the global entry point or the analyzer would simply execute the script and return without crawling the exposed API. Note that we don’t have to tell the analyzer any details about the API. No type information, no annotations, no test data.

Thrown exceptions and runtime errors

The analyzer does not report an intentionally thrown exception as a runtime error if there is an alternative, valid execution path. Thrown exceptions are still part of the report, but they don’t cause the build to fail. Consider this function:

var expected = 'number'
function toAmount(n) {
if (typeof n !== expected)
throw new Error('Argument must be ' + expected)
  return n.toFixed(2)
}

The call tree shows that the toAmount function throws and the report shows the computed error message:

However, the combination of the exception and the conditional is used to conclude what the type of n must be. Changing the toFixed call to something that isn’t valid on a number, let’s say return n.indexOf('.'), would result in a runtime error. If the toAmount function is invoked with something other than a number explicitly, the thrown exception is reported as a runtime error too.

Playing with the free tier

When you sign in to JavaScript Studio with your GitHub account, you’re automatically subscribed to the free tier. You can play with the new web interface, or use the open source command line tool to invoke the analyzer. The free tier is renewed every month, allowing you to regularly analyze smaller libraries entirely free. Give it a try!

For example, you could grab the souce code of Lolex, set lolex as the entry point to see what the API looks like.

What’s coming next?

The analyzer will soon learn how to invoke XMLHttpRequest handlers automatically. Development to support ES 6 has also started. If you want to analyze ES 6 scripts today, check out the documentation on how to use Babel with JavaScript Studio.

Should you run into issues or want to suggest a feature, please get in touch! Comment below or reach out to @javascriptstdio on Twitter.

Thanks for reading! 👏