Feb 122015

As I’ve promised in my previous post, I am going to continue describing my experience with Aurelia.

The first thing that I’ve noticed while working with the framework is that the default template does not enable source maps. Source maps are files with the .js.map extension which “tell” the browser or debugger how to map the transpiled (JavaScript) code to the original script (ES6 or TypeScript). This means that if you have the correct sourcemaps, you are able to debug the code you’ve written using ES6 directly in the browser, even though in reality it is running pure javascript. This works in a similar way to how PDB files work in .NET when debugging C# or VB applications.

If you don’t have sourcemaps, then you’re making your life much harder because you’ll be looking at the generated (transpiled) javascript which sometimes is not the easiest to read (BTW I will come back to this subject a bit later).

Enabling source maps for your Aurelia project

In order to add support for these sourcemaps, you need to use the “gulp-sourcemaps” library. There are two steps to this:

Step 1 – edit the packages.json file located in the project root and under “devDependencies” add the following line:

"gulp-sourcemaps": "^1.3.0"

This will ensure that when you build the project, the node package manager (npm) will install this dependency and you will be able to use it in your build process. Which takes us to:

Step 2 – change the gulpfile.js in the project root to add source map generation

You need to add the following line somewhere at the beginning of the file (after all require statements is a good place):

var sourcemaps = require('gulp-sourcemaps');

Source map generation conflicts with the default compiler settings, so you will need to comment out (or delete) the sourceMapName and sourceFileName compiler options.

Search for the “build-system” task and replace it with the following:

gulp.task('build-system', function () {
    return gulp.src(path.source)
        .pipe(changed(path.output, {extension: '.js'}))
        .pipe(to5(assign({}, compilerOptions, {modules: 'system'})))

This change will actually “inject” the sourcemaps plugin in the build pipeline. The end result is that whenever the project gets built, it will generate one *.js.map file for each transpiled file (inside the dist folder). The second effect, as stated above is that you will be able to debug using FireBug or Chrome Developer Tools directly the ES6 source code and the browser will internally map the breakpoints and code lines to the transpiled code.

Get the entire gulp.js file here: https://gist.github.com/nseba/369f0184d587b7235caa


One of the things that gets annoying relatively quick is the fact that the Aurelia framework that gets installed using the official Getting Started guide will contain only the transpiled files. Together with the extremely thin documentation available right now, you will have to do a lot of digging in the Aurelia’s github repositories to figure out how some things are working. This is unfortunately not so easy all the time, but hopefully this will get better once the project is more mature.

The only thing that I would have liked more from the framework would have been to include the ES6 source of Aurelia and to build it normally together with my code. This would generate the correct source maps and debugging would be much easier.

Another caveat comes when using source maps for debugging is that even if the browser can track the application execution and match it with the ES6 source code, there are some situations in which you need to be aware that you are actually still running Javascript. An example of such a situation is when having a breakpoint inside a ES6 lambda (arrow function) body. Since in ES6 (same is in TypeScript) lambdas will capture the outer this, it means that you can  write code like this:

class A
        this.x = 1;

       this.onclick = () => {
           this.x += 1;     // "this.x" will refer to the same member field x defined in the constructor above because lambdas capture the this from the parent scope.

The trick here is that the compiled code will look something like (NOTE: this is not 100% how it gets transpiled):

class A
       this.x = 1;
       var _this = this;
       this.onclick =  function () {
           _this.x += 1;     // notice the use of the _this variable to capture the this from the outer scope

When you have the breakpoint set inside the onclick function, the developer tools (or FireBug) will show you the original code with this.x += 1. But if you add the “this” to the watch, you will notice it’s undefined or it has some unexpected value (typically it is thee value of the  window object). To be able to debug correctly, you’ll need to add the “_this” to the watch. This is one very common issue that you’ll encounter while working with any transpiled language.

In the next post I will discuss some basic aspects of running the project and writing logging information using the provided framework. This should cover the minimum required to run and debug the application.

Final notes

Based on the messages that I’ve received, I’ve also checked out various TypeScript Aurelia-based frameworks. While I am a big fan of TypeScript, I am not going to switch to that for several reasons:

  1. The type definitions are at the moment incomplete. This means that you’ll have to update them by hand which can become a rather complex task due to the early nature of the Aurelia project.
  2. I really like the string interpolation feature from ES6. I’m looking forward to the moment TypeScript will support this.
  3. The import mechanism for ES6 is way cleaner than the one in TypeScript. This is another point where I hope TypeScript will be adjusted because it results in much cleaner code.
  4. Overall the language features provided by ES6 make things much cleaner and easier to write. Looking at the TypeScript roadmap, it might become really attractive if it adopts more of the ES6 standard features.

Anyway, given the above, when the TypeScript framework is good enough, the transition can be made relatively easy from ES6 to TS.

Feb 012015

As I’ve promised, I will start documenting my experience with Aurelia. If you haven’t read my previous introduction article, click here to get an insight of what Aurelia is.

Since I’m writing this post during Sunday night, I will keep it short and just talk about tooling.

I am not the hacker-notepad-vim kind of guy and the first thing that I need when I work with any technology/framework is a good IDE. I’m a veteran user of Visual Studio + Resharper, so obviously my first choice when starting with Aurelia was to use this.

Unfortunately, VS 2013 + Resharper does not currently have any support for ES6 so it kind of stands in your way. Of course you can still use it as a text editor, but it’s even worse than using any notepad alternative since it always highlights the whole code as having errors and the formatting just messes things up (misaligned curly brackets or parenthesis, wrong spacing etc.).

After searching a bit on the internet and almost loosing all hope to have a nice IDE for this, I found out that JetBrains Webstorm IDE actually has support for ES6, so I will be using this from now on for my experiments.

Just as a hint, if you want to set Webstorm up, check out this short video on how to use Webstorm + Traceur. The default Aurelia template already transpiles ES6 to Javascript, but if you want a more integrated experience, you can configure the IDE to do it for you:



Nov 012013

A lot of people involved in web development (including myself) have hit a problem with the latest versions of jQuery. Right now there are two versions of jQuery available on NuGet – 1.9.1 and 2.0.x. According to the jQuery team, both versions will be developed in the future and for developers targeting web applications the recommended version is 1.9.1 instead of 2.0 (jQuery UI for example does not work with v2.0).

By default NuGet will install the latest version of jQuery automatically. Of course, if you use the Package Manager Console, you can force version 1.9.1. But as soon as you update and you forget to do a safe update (see my previous post here on how to do that), you are stuck with version 2.0.

To prevent such issues, an easy solution is to force the package to stay under version 2.0 by changing it in the packages.config file like this:

<package id="jQuery" version="1.9.1" targetFramework="net45" allowedVersions="[1.9.1,2)" />

The right parenthesis means that the allowed versions should go up to (but not including) version 2.0

In the nasty situation when you’ve already updated the version and you have also dependencies on jQuery, you can downgrade the version using the following Package Manager Console commands:

Uninstall-Package jQuery –Force Install-Package jQuery -Version 1.9.1

Remember to change the packages.config afterwards.

Sep 242013

This is a follow-up on my previous post with a slight variation of the command. If your package source contains pre-release packages, then the previous command is not enough. The change is minor, though:

Get-Package –Updates -IncludePrerelease | ForEach-Object { Update-Package $_.Id –Safe -IncludePrerelease }

This will include all prerelase packages in the update.

Apr 152013

there are situations when you need to update the referenced NuGet packages and use a safe update.Safe update means that the packages are updated to the latest version that has the same major version as the current one. For example: suppose the project has a reference to “MyPackage” version In the NuGet repository there is a MyPackage version and one with version

A safe update would update the package to the version, while a regular update would update it to the latest version ( While the safe update can be done using the package manager UI from Visual Studio, the safe update requires using the powershell console directly.

Fortunately, there is a very easy way of updating safely all references. Open the Package Manager Console (Tools->Library Packager->Package Manager Console) and type the following command:

Get-Package –Updates | ForEach-Object { Update-Package $_.Id –Safe }

Feb 052013

How many times you had to build a console application that must receive various input arguments? I know I did a lot of times – from small development tools to various applications. And every time there was a big PITA to handle the input arguments. Every time I have reinvented the wheel, every time I had to check for the arguments, parse them, output various help messages etc.

Continue reading »

Aug 022011

As a WPF developer, I often find myself trying to debug the visual structure of my applications or to find out why something doesn’t work as expected. The Visual Studio debugger can help up to a certain point, but for runtime visual debugging it lacks the necessary features. Luckily, there is an awesome free tool that you can use for this – Snoop. The tool itself is very straightforward – you select your running application press a button and you can see the whole visual tree:

Continue reading »

Jul 282011

I find that with the extension support in VS2010, programmers don’t really have an excuse for not using tools to increase their productivity and to increase the overall quality of their work. I am a really lazy programmer, in the sense that I don’t’ like to do repetitive boring tasks. Extensions are one of the solutions to being a happy lazy programmer. The other one is writing quality code, but that’s another story. So here is a list of all Extensions that I use in day-to-day work

Shout it
Continue reading »

May 172011


I often work on various branches of the same project (using TFS). This means that I have folders setup like:


[root]/Branch A/Project

[root]/Branch X/Project

Sometimes I have to keep multiple Visual Studio instances open at the same time with branches of the same project and because by default VS2010 only displays the solution name in the title bar, switching between different windows can become very confusing.

Continue reading »