Source Maps Are Here!

In the previous blog post I talked about the exciting new feature of highlighting exactly where the error is, in your code. The fact that this is even possible to do externally, is the kind of stuff that distinguishes JavaScript from all other languages. It is why Errorception has this singular focus on JavaScript.

This post is to highlight one more such feature — source maps.

If you have errors in your minified code and Errorception's crawler discovers a source-map file associated with your code, it downloads the source-map file and your associated original source files, and versions & saves it in Errorception's file store. After that, all the goodness of pointing out the error isn't just applied to your minified file, but also to your original source-code.

Mapped! Showing you the error in your un-minified source!

Errorception shows you exactly where the error is in your original, unminified source-code. Not just that, it does all of this automatically, and across all your stack frames! Isn't that just awesome?

You just need to make your source-map file available, and Errorception will do the rest. The tweaks needed to your build script are real simple too — it's usually just a flag in most minifiers.

Your minified code is just a click away. Note the tabs at the top-right of your code.

Source maps have been around for some time now. However, I didn't want to implement source maps just so Errorception could wear it as a badge — I wanted to make it actually useful to you. The previous release was a step in this direction — putting your code front and center, and pointing out exactly where the error was in your deployed code. Now, source-maps completes this by not only pointing out exactly the token that caused the error, but also by doing so in your original unminified source file.

Oh, and of course, this also means that Errorception now supports compile-to-JS languages as well. CoffeeScript, TypeScript, ClojureScript and others, welcome to Errorception! You should feel at home.

As always, suggestions and feedback always welcome. Mail, Tweet, or leave a comment below.

Here's Your Error!

Today's release is a game changer!

Now, whenever possible, your code and stack-traces take center stage in your error reports. Errorception looks at your code and the data from the error, and attempts to point out where exactly in your source file the error occurred.

Although the logic that points out your errors only gets incomplete data to work with, the predictions it makes about the error's cause are stunningly accurate in most cases. Not only does it point out the exact line and column number of the error, it also tries to make sense of your code to find the exact keyword or token that caused the error. And it does this across all stack frames!

Two stack frames of an error

See that screaming out: "Here's your error!" Isn't it just amazing how accurate it is? Do you see how easily you will be able to smash bugs with this?

Browser support

This feature relies somewhat heavily on stack-traces being available. All recent versions of Chrome (Desktop and Android) provide stack-traces in window.onerror out of the box, so you are already covered there. Stack-traces in window.onerror are new, having made it into the spec only recently. Firefox just implemented this about a week ago, so I expect the next release will ship with window.onerror stack traces. This also works for errors from IE10 for at least the first stack-frame, since IE10 provides a column number for every window.onerror error.

Additionally, this works just about everywhere if you .push your errors to Errorception. Until recently, Firefox didn't provide column numbers in their stacks, but that just got fixed a couple of days ago, expanding browser support to all popular browsers. In older versions of Firefox, you should still be able to see the highlight for the first stack-frame for .pushed errors.

It even works accurately with minified code!

If it isn't possible to highlight the offending keyword/token, Errorception will attempt to highlight the offending column. Errorception will definitely highlight the line of the error in all cases regardless.

The tech

The engineering needed to pull this off has been significant — certainly one of the more complex things I've worked on. At its heart lies a file-store, written from scratch, purpose-built for just this job. A crawler spiders your site for your JS files when errors occur, and saves them in the file-store, which caches and versions your files. This caching and versioning ensures that you see the rightest possible version of the file that caused the error, even if the file might have subsequently changed with new updates. Your files and the history of your error occurrences are then mined to figure out what might have caused the error.

There are no settings to be configured, no knobs to be turned — It All Just Works. Best of all, this is all done without any extra work on the client-side at all, so your users don't face any performance penalty whatsoever.

This release has been brewing for months, and has been in closed beta for a few weeks now. And today's feature isn't even the main reason I built all of this — it's just an awesome side-effect. But I'll save those details for the next blog post. (Can you spot it?)

As usual, feedback always welcome. Mail, Tweet or leave a comment below.