One of the most frustrating things about JavaScript development is the lack of a compilation step. JavaScript is an interpreted language, and therefore needs to be run in order to test that it is valid. Every JavaScript developer will tell horror stories of hours spent trying to find bugs in their code, only to find that they have missed a stray closing brace { , or a simple comma , - or even a double quote " where there should have been a single quote '. Even worse, the real headaches arrive when you misspell a property name, or unwittingly re-assign a global variable.

TypeScript will compile your code, and generate compilation errors where it finds these sort of syntax errors. This is obviously very useful, and can help to highlight errors before the JavaScript is run. In large projects, programmers will often need to do large code merges – and with today's tools doing automatic merges – it is surprising how often the compiler will pick up these types of errors.

While tools to do this sort of syntax checking – like JSLint – have been around for years, it is obviously beneficial to have these tools integrated into your IDE. Using TypeScript in a continuous integration environment will also fail a build completely when compilation errors are found – further protecting your programmers against these types of bugs.

JavaScript is not strongly typed. It is a language that is very dynamic, as it allows objects to change their properties and behavior on the fly. As an example of this, consider the following code:

var test = "this is a string";
test = 1;
test = function(a, b) {
    return a + b;
}

On the first line of this code snippet, the variable test is bound to a string. It is then assigned a number, and finally is redefined to be a function that expects two parameters. Traditional object oriented languages, however, will not allow the type of a variable to change – hence they are called strongly typed languages.

While all of the preceding code is valid JavaScript - and could be justified - it is quite easy to see how this could cause runtime errors during execution. Imagine that you were responsible for writing a library function to add two numbers, and then another developer inadvertently re-assigned your function to instead subtract these numbers.

These types of errors may be easy to spot in a few lines of code, but it becomes increasingly difficult to find and fix these as your code base, and your development team grows.

Another feature of strong typing is that the IDE you are working in can understand what type of variable you are working with, and can bring better autocomplete or Intellisense options to the fore.

var test: string = "this is a string";
test = 1;
test = function(a, b) { return a + b; }

error TS2011: Build: Cannot convert 'number' to 'string'.
error TS2011: Build: Cannot convert '(a: any, b: any) => any' to 'string'.

As we have seen, TypeScript has the ability to "annotate" JavaScript, and bring strong typing to the JavaScript development experience. But how do we strongly type existing JavaScript libraries? The answer is surprisingly simple: by creating a definition file. TypeScript uses files with a .d.ts extension as a sort of "header" file, similar to languages such as C++, to superimpose strongly typing on existing JavaScript libraries. These definition files hold information that describes each available function and variable of the library, along with their associated type annotations.

Let's take a quick look at what a definition would look like. As an example, consider a function from the popular Jasmine unit testing framework called describe:

var describe = function(description, specDefinitions) {
  return jasmine.getEnv().describe(description, specDefinitions);
};

This function has two parameters, description and specDefinitions. Just reading this JavaScript, however, does not tell us what sort of parameters these are meant to be. Is the specDefinitions argument a string, or an array of strings, a function or something else? In order to figure this out, we would need to have a look through the Jasmine documentation found at http://jasmine.github.io/2.0/introduction.html. This documentation provides us with a helpful sample of how to use this function:

describe("A suite", function () {
    it("contains spec with an expectation", function () {
        expect(true).toBe(true);
    });
});

From the documentation, then, we can easily see that the first parameter is a string, and the second parameter is a function. There is nothing in the JavaScript language, however, that forces us to conform to this API. As mentioned before, we could easily call this function with two numbers – or inadvertently switch the parameters around, sending a function first, and a string second. We will obviously start getting runtime errors if we do this, but TypeScript – using a definition file – can generate compile time errors before we even attempt to run this code.

Let's take a look at a piece of the jasmine.d.ts definition file:

declare function describe(
    description: string, specDefinitions: () => void
): void;

This is the TypeScript definition for the describe function. Firstly, declare function describe tells us that we can use a function called describe, but that the implementation of this function will be provided at runtime.

Clearly, the description parameter is strongly typed to be of type string, and the specDefinitions parameter is strongly typed to be a function that returns void. TypeScript uses the double braces () syntax to declare functions, and the fat arrow syntax to show the return type of the function. So () => void is a function that does not return anything. Finally, the describe function itself will return void.

If our code were to try and pass in a function as the first parameter, and a string as the second parameter (clearly breaking the definition of this function) as shown in the following example:

describe(() => { /* function body */}, "description");

The TypeScript compiler will immediately generate the following errors:

error TS2082: Build: Supplied parameters do not match any signature of call target: Could not apply type "string" to argument 1 which is of type () => void

This error is telling us that we are attempting to call the describe function with invalid parameters. We will look at definition files in more detail in later chapters, but this example clearly shows that TypeScript will generate errors if we attempt to use external JavaScript libraries incorrectly.

One of the fundamental principles of object-oriented programming is encapsulation: The ability to define data, as well as a set of functions that can operate on that data, into a single component. Most programming languages have the concept of a class for this purpose – providing a way to define a template for data and related functions.

Let's first take a look at a simple TypeScript class definition:

class MyClass {
    add(x, y) {
        return x + y;
    }
}

var classInstance = new MyClass();
console.log(classInstance.add(1, 2));

This code is pretty simple to read and understand. We have created a class, named MyClass, with a single function named add. To use this class, we simply create an instance of it, and call the add function with two arguments.

JavaScript, unfortunately, does not have a class keyword, but instead uses functions to reproduce the functionality of classes. Encapsulation through classes is accomplished by either using the prototype pattern, or by using the closure pattern. Understanding prototypes and the closure pattern, and using them correctly, is considered a fundamental skill when writing enterprise-scale JavaScript.

A closure is essentially a function that refers to independent variables. This means that variables defined within a closure function 'remember' the environment in which they were created. This provides JavaScript with a way to define local variables, and provide encapsulation. Writing the MyClass definition in the preceding code, using a closure in JavaScript would look something like this:

var MyClass = (function () {
    // the self-invoking function is the 
    // environment that will be remembered
    // by the closure
    function MyClass() {
        // MyClass is the inner function,
        // the closure
    MyClass.prototype.add = function (x, y) {
        return x + y;
    };
    return MyClass;
})();
var classInstance = new MyClass();
console.log("result : " + classInstance.add(1, 2));

We start with a variable called MyClass, and assign it to a function that is executed immediately – note the })(); syntax near the bottom of the code snippet. This syntax is a common way to write JavaScript in order to avoid leaking variables into the global namespace. We then define a new function named MyClass, and return this new function to the outer calling function. We then use the prototype keyword to inject a new function into the MyClass definition. This function is named add and takes two parameters, returning their sum.

The last two lines of the code show how to use this closure in JavaScript. Create an instance of the closure type, and then execute the add function. Running this in the browser will log result: 3 to the console, as expected.

Looking at the JavaScript code versus the TypeScript code, we can easily see how simple TypeScript looks, compared to the equivalent JavaScript. Remember how we mentioned that JavaScript programmers can easily misplace a brace {, or a bracket (? Take a look at the last line in the closure definition: })(); Getting one of these brackets or braces wrong can take hours of debugging to find.

A further object-oriented principle that is used in encapsulation is the concept of data hiding – the ability to have public and private variables. Private variables are meant to be hidden to the user of a particular class – as these variables should only be used by the class itself. Inadvertently exposing these variables outside of a class can easily cause runtime errors.

Unfortunately, JavaScript does not have a native way of declaring variables private. While this functionality can be emulated using closures, a lot of JavaScript programmers simply use the underscore character _ to denote a private variable. At runtime though, if you know the name of a private variable – you can easily assign a value to it. Consider the following JavaScript code:

var MyClass = (function() {
    function MyClass() {
        this._count = 0;
    }
    MyClass.prototype.countUp = function() {
        this._count ++;
    }
    MyClass.prototype.getCountUp = function() {
        return this._count;
    }
    return MyClass;
}());

var test = new MyClass();
test._count = 17;
console.log("countUp : " + test.getCountUp());

The MyClass variable is actually a closure – with a constructor function, a countUp function and a getCountUp function. The variable _count is supposed to be a private member variable, one that is used only within the scope of the closure. Using the underscore naming convention gives the user of this class some indication that the variable is private, but JavaScript will still allow you to manipulate the variable _count. Take a look at the second last line of the code snippet. We are explicitly setting the value of the supposed private variable _count to 17 – which is allowed by JavaScript, but not desired by the original creator of the class. The output of this code would be countUp: 17.

TypeScript, however, introduces the public and private keywords that can be used on class member variables. Trying to access a class member variable that has been marked as private will generate a compile time error. As an example of this, the JavaScript code above can be written in TypeScript as follows:

class MyClass {
    private _count: number;
    constructor() {
        this._count = 0;
    }
    countUp() {
        this._count++;
    }
    getCount() {
        return this._count;
    }
}

var classInstance = new MyClass();
console.log(classInstance._count);

On the second line of our code snippet, we have declared a private member variable named _count. Again, we have a constructor, a countUp and a getCount function. If we compile this TypeScript code, the compiler will generate an error:

error TS2107: Build: 'MyClass._count' is inaccessible.

This error is generated because we are trying to access the private variable _count in the last line of the code.

The TypeScript compiler, therefore, is helping us to adhere to public and private accessors – by generating a compile error when we inadvertently break this rule.

Once Visual Studio is installed, fire it up and create a new project (File | New Project). Under the Templates section on the left hand side, you will see a TypeScript option. When this option is selected, you will be able to use a project template named Html Application with TypeScript. Enter a name and location for your project, and then click OK to generate a TypeScript project:

Visual Studio – selecting the TypeScript project type

Once a new TypeScript project is created, notice that the project template generates a few files for us automatically:

If we were to compile and then run this project now, we would have a complete, running TypeScript application right off the bat:

Visual Studio index.html running in Internet Explorer

Let's take a quick look at the generated index.html file and what it contains:

<!DOCTYPE html>

<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>TypeScript HTML App</title>
    <link rel="stylesheet" href="app.css" type="text/css" />
    <script src="app.js"></script>
</head>
<body>
    <h1>TypeScript HTML App</h1>

    <div id="content"></div>
</body>
</html>

This is a very simple HTML file, which includes the app.css style sheet, as well as a JavaScript file named app.js. This app.js file is the JavaScript file that is generated from app.ts TypeScript file, when the project is compiled.

One of the best features of Visual Studio is that it is truly an integrated environment. Debugging TypeScript in Visual Studio is exactly the same as debugging C# – or any other language in Visual Studio – and includes the usual Immediate, Locals, Watch and Call stack windows.

To debug TypeScript in Visual Studio, simply put a breakpoint on the line you wish to break on in your TypeScript file (Move your mouse into the breakpoint area next to the source code line, and click). In the image below, we have placed a breakpoint within the window.onload function.

To start debugging, simply hit F5.

Visual Studio TypeScript editor with a breakpoint set in the code

When the source code line is highlighted in yellow, simply hover your mouse over any of the variables in your source, or use the Immediate, Watch, Locals or Call stack windows.

Visual Studio debug toolbar showing browser options

To create a new WebStorm project, simply fire it up, and hit File | New Project. Select a Name, Location and Project type. For this project, we have chosen Twitter Bootstrap as the project type, as shown in the following screenshot:

WebStorm Create New Project dialog box

WebStorm will then ask you to select the version of Twitter Boostrap that you intend developing for. In this example, we have chosen version v3.2.0.

WebStorm Select Twitter Boostrap version dialog box

WebStorm has conveniently created a css, fonts and js directory as part of the new project – and downloaded and included the relevant CSS, font files and JavaScript files for us, in order to start building a new Bootstrap based website. Note that it has not created an index.html file for us, nor has it created any TypeScript files – as Visual Studio did. After a while working with TypeScript, most developers will delete these generic files anyway. So lets create an index.html file.

Simply click on File | New, select HTML file, enter index as a name, and click OK.

Next, let's create a TypeScript file in a similar manner. We will call this file app (or app.ts), to be the same as in the Visual Studio default project example. As we click inside the new app.ts file, WebStorm will pop up a green bar at the top of our edit window, with a suggestion reading File watcher 'TypeScript' is available for this file, as shown in the following screenshot:

WebStorm editing a TypeScript file for the first time showing the File Watcher bar

A WebStorm "file watcher" is a background process that will execute as soon as you have saved the file. This is equivalent to Visual Studio's Compile on save TypeScript option. As WebStorm suggests, now would be a good time to activate this file watcher for TypeScript. Click on the Add watcher link in the green bar, and fill in the details on the next screen.

We can leave the defaults on the next screen as they are for the time being, except for the Program setting:

If you are running on Windows, and already have Visual Studio installed, then this should be set to the full path of the tsc.exe executable, i.e. C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\tsc.exe, as shown in the following screenshot:

If you are running on a non-windows box, or have installed TypeScript via Node, then this would just be set to tsc, with no path.

WebStorm new file watcher options screen

Now that we have a file watcher created for our TypeScript files, lets create a simple TypeScript class, which will modify the innerText of an HTML div. While you are typing, you will notice WebStorm's autocompletion or Intellisense feature helping you with available keywords, parameters, naming conventions and a host of other language specific information. This is one of the most powerful features of WebStorm, and is similar to the enhanced Intellisense seen in JetBrain's Resharper tool for Visual Studio. Go ahead and type the following TypeScript code, during which you will get a good feeling of WebStorm's available autocompletion.

class MyClass {
    public render(divId: string, text: string) {
        var el: HTMLElement = document.getElementById(divId);
        el.innerText = text;
    }
}

window.onload = () => {
    var myClass = new MyClass();
    myClass.render("content", "Hello World");
}

We start off with the MyClass class definition, which simply has a function called render. This render function takes a DOM element name, and a text string as parameters. It then simply finds the DOM element, and sets the innerText property. Note the use of strong typing on the variable el – we have explicitly typed this to be of the HTMLElement type.

We are also assigning a function to the window.onload event, which will execute once the page has been loaded, similar to the Visual Studio sample. Within this function, we are simply creating an instance of MyClass, and calling the render function with two string arguments.

If you have any errors in your TypeScript file, these will automatically show up in the output window, giving you instant feedback while you type. With this TypeScript file created, we can now include it in our index.html file, and try some debugging.

Open the index.html file, and add a script tag to include the app.js JavaScript file, along with a div with an id of "content". Just as we saw with TypeScript editing, you will find that WebStorm has powerful Intellisense features when editing HTML as well.

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
    <script src="app.js" type="application/javascript"></script>
</head>
<body>
    <h2>Index.html</h2>
    <div id="content"></div>
</body>
</html>

There are a couple of points to note in the preceding code. We are including a script tag for the app.js JavaScript file, as this is the output file that the TypeScript compiler will generate. We have also created an HTML <div> with an id of content that the instance of the MyClass class will use to render our text.

When viewing or editing HTML files in WebStorm, you will notice a small set of browser icons popping up on the top right corner of the editing window. Clicking on any one of the icons will launch your current HTML page using the selected browser.

WebStorm editing an HTML file showing the popup browser launching icons

As we saw in Visual Studio, debugging in WebStorm is simply a matter of marking a breakpoint, and then hitting Alt + F5. WebStorm uses a Chrome Plugin to enable debugging in Chrome. If you do not have this plugin installed, WebStorm will prompt you the first time you start debugging, to download and enable the JetBrains IDE Support Chrome Plugin. With this plugin enabled, WebStorm has a very powerful set of tools to inspect JavaScript code, add watchers, view the console and many more, right inside the IDE.

WebStorm debugging session showing debugger panels

Brackets can be downloaded with the preferred installers from http://brackets.io. Once installed, we will need to install some extensions. Brackets has a really slick and simple extension manager, which is easy to use, and which allows us to easily find and install available extensions. Any time an update to either Brackets, or one of your installed extensions is available, Brackets will automatically notify you.

To install an extension, fire up Brackets, and either click on File | Extension Manager, or click on the lego-block icon on the right-hand side vertical sidebar.

To start with, we will need to install the TypeScript extension. In the search bar, type brackets typescript, and install the Brackets TypeScript extension from Francois de Campredon.

As can be seen from the following screenshot, each extension has a More info… link – which will take you to the extension home page.

Brackets Extension manager interface

As well as the Brackets TypeScript extension, another useful extension is Code Folding by Patrick Oladimeji. This will allow you to collapse or expand sections of code in any file that you are editing.

Another great time-saver is Emmet by Sergey Chikujonok. Emmet (previously known as Zen Coding) uses a CSS-like short-hand, instead of traditional code snippets, to generate HTML. In this section, we will quickly show how Emmet can be used to generate HTML, just as a teaser. So go ahead and install the Emmet extension.

Brackets does not have the concept of a project per se, but instead just works off a root folder. Create a directory on your filesystem, and then open that folder in Brackets: File | Open Folder.

Let's now create a simple HTML page using Brackets. Select File | New, or Ctrl + N. With a blank file in front of us, we will use Emmet to generate our HTML. Type in the following Emmet string:

html>head+body>h3{index.html}+div#content

Now hit Ctrl + Alt + Enter, or from the File menu, select Emmet | Expand Abbreviation.

Voila! Emmet has generated the following HTML code in a millisecond - not bad for one line of source code:

<html>
<head></head>
<body>
    <h3>index.html</h3>
    <div id="content"></div>
</body>
</html>

Hit Ctrl + S to save the file, and enter index.html.

Back to Emmet.

Emmet uses the > character to create a child, and the + character to denote a sibling. If you specify curly braces { } next to an element, this will be used as the text content.

The Emmet string that we entered previously basically said: "create an html tag with a child head tag. Then create another child tag of html named body, create a child h3 tag with the text "index.html", and then create a sibling div tag as a child of body with the id of content." Definitely head over to http://emmet.io for further documentation, and remember to keep the cheat-sheet handy (http://docs.emmet.io/cheat-sheet), when you are learning Emmet string shortcuts.

Now lets finish off our index.html with an app.js script to load our TypeScript generated JavaScript file. Move your cursor in-between the <head></head> tags, and type another Emmet string:

script:src

Now hit Ctrl + Alt + Enter, to have Emmet generate a <script src=""></script> tag, and conveniently place your cursor between the quotes ready for you to simply fill in the blanks. Now type the JavaScript filename, app.js.

Your completed index.html file should now look as follows:

<html>
<head>
    <script src="app.js"></script>
</head>
<body>
    <h3>index.html</h3>
    <div id="content"></div>
</body>
</html>

This is all we need for our sample HTML page.

Within Brackets, click on the live preview icon on the far right of the screen – it's the electric zig zag one – just above the lego-block packages icon. This will launch Chrome and render our index.html in live preview mode. Just to show how Brackets can be used for live preview, keep this Chrome window visible, and navigate back to Brackets. You should be able to see both windows at the same time.

Now edit the index.html file, and type the following Emmet shorthand under your <div id="content"></div> element:

ul>li.item$*5

Again, hit Ctrl + Alt + Enter, and note how the generated <ul> and <li> tags (5 of them) are automatically displayed in your Chrome browser. As you move your caret up or down in the source code, notice how the blue outline in Chrome shows the element in the web page.

Brackets running Chrome in live preview mode, showing highlighted elements

We won't be needing these <ul> <li> tags for our application, so simply Ctrl + Z, Ctrl + Z to undo our changes, or delete the tags.

To create our very simple TypeScript application, hit Ctrl + N (new file), Ctrl + S (save file) and use app.ts as your file name. Start typing the following code, and notice how Brackets also does autocompletion, or Intellisense on the fly, similar to Visual Studio and WebStorm:

class MyClass {
    render( elementId: string, text: string) {
        var el: HTMLElement = document.getElementById(elementId);
        el.innerHTML = text;
    }
}
window.onload = () => {
    var myClass = new MyClass();
    myClass.render("content", "Hello world!");
}

This is the same code that we used previously, and simply creates a TypeScript class named MyClass that has a single render function. This render function gets a DOM element, and modifies it's innerHTML property. The window.onload function creates an instance of this class, then calls the render function with the appropriate parameters.

If you save the file by hitting Ctrl + S at any stage, Brackets will invoke the TypeScript language engine to verify our TypeScript, and render any errors in the bottom window pane. In the following screenshot, we can clearly see that we are missing a closing brace }.

Brackets editing a TypeScript file and showing compile errors

Brackets will not invoke the TypeScript compiler to generate an app.js file – it just parses the TypeScript code at this stage, and highlights any errors. Double-clicking on the error in the TypeScript Problem pane will jump to the line in question.

Before we are able to run our application, we will need to compile the app.ts file into an app.js file by invoking the TypeScript compiler. Open up a Command Prompt, change to your source directory, and simply type:

tsc app.ts

This command will invoke the tsc command line compiler, and create an app.js file from our app.ts file.

Now that we have an app.js file in this directory, we can invoke the live preview button again, and now see that our TypeScript application has indeed rendered the Hello world! text as the innerHTML of the content div:

Brackets live preview running our TypeScript application

Obviously, it is going to be very tedious to have to switch to the Command Prompt and manually compile each TypeScript file every time we have made a change. Grunt is an automated task runner (http://gruntjs.com) that can automate many tedious compile, build, and testing tasks. In this section, we will use Grunt to watch TypeScript files, and invoke the tsc compiler when a file is saved. This is very similar to WebStorm's file watch functionality that we used earlier.

Grunt runs in a Node environment. Node is an open-source, cross platform runtime environment, whose programs are written in JavaScript. To run Grunt, we will therefore need to install Node. Installers for Windows, Linux and OS X can be found from the Node website (http://nodejs.org/). Once Node is installed, we can use npm (Node package manager) to install Grunt and the Grunt command line interface.

Grunt needs to be installed as an npm dependency of your project. It cannot be installed globally, the way most npm packages can. In order to do this, we will need to create a packages.json file in the root project. Open up a Command Prompt, and navigate to the root directory of your Brackets project. Then simply type:

npm init

And follow the prompts. You can pretty much leave all of the options as their default, and always go back to edit the packages.json file that is created from this step, should you need to tweak any changes. With the package initialization step complete, we can now install Grunt as follows:

npm install grunt –save-dev

The -save-dev option will install a local version of Grunt in the project directory. This is done so that multiple projects on your machine can use different versions of Grunt. We will also need the grunt-typescript package, as well as the grunt-contrib-watch package. These can be installed with the following npm commands:

Npm install grunt-typescript –save-dev
Npm install grunt-contrib-watch –save-dev.

Lastly, we will need a GruntFile.js as the entry point for Grunt. Using Brackets, create a new file, save it as GruntFile.js, and enter the following JavaScript. Note that we are creating a JavaScript file here, not a TypeScript file. You can find a copy of this file in the sample source code that accompanies this chapter.

module.exports = function (grunt) {
    grunt.loadNpmTasks('grunt-typescript');
    grunt.loadNpmTasks('grunt-contrib-watch');
    grunt.initConfig({
        pkg: grunt.file.readJSON('package.json'),
        typescript: {
            base: {
                src: ['**/*.ts'],
                options: {
                    module: 'commonjs',
                    target: 'es5',
                    sourceMap: true
                }
            }
        },
        watch: {
            files: '**/*.ts',
            tasks: ['typescript']
        }
    });

   //grunt.registerTask('default', ['typescript']);
    grunt.registerTask('default', ['watch']);
}

This GruntFile.js is necessary to setup all of the Grunt tasks. It is a simple function that Grunt uses to initialize the Grunt environment, and specify the Grunt commands. The first two lines of the function are loading grunt-typescript and grunt-contrib-watch tasks, and then runs the grunt.initConfig function with a configuration section. This configuration section has a pkg property, a typescript property and a watch property. The pkg property is set by reading the package.json file that we created earlier as part of the npm init step.

The typescript property has a base property, in which we are specifying that the source should be '**/*.ts' – in other words, all .ts files in any subdirectory. We are also specifying some TypeScript options – using 'commonjs' modules instead of 'amd' modules, and generating sourcemaps.

The watch property has two sub-properties. The files property specifies to watch for any .ts files in our source tree, and the tasks array specifies that we should kick off the TypeScript command once a file has been changed. Finally we call grunt.registerTask, specifying that the default task is to watch for file changes. Grunt will run in the background watching for saved files, and if found, will execute the TypeScript task.

We can now run Grunt from the command line. Make sure that you are in the Brackets project base directory, and fire up Grunt:

Grunt

Open up your app.ts file, make a small change (add a space or something), and then hit Ctrl + S to save. Now check back on the output from the Grunt command line. You should see something like this:

>> File "app.ts" changed.
Running "typescript:base" (typescript) task
2 files created. js: 1 file, map: 1 file, declaration: 0 files (861ms)
Done, without errors.
Completed in 1.665s at Fri Oct 10 2014 11:24:47 GMT+0800 (W. Australia Standard Time) - Waiting...

This command line output is confirmation that the Grunt watch task has identified app.ts has having changed, run the TypeScript task, created two files, and is now waiting for the next file to change. Flicking back to Brackets, we should now see the app.js file created by Grunt in the Brackets file pane.

Since Brackets is just being used as an editor, we will need to debug our applications using the standard Chrome development tools. One option that we specified in our GruntFile.js for TypeScript was to turn on sourcemaps (options { sourceMap : true }). With this option, Chrome – and other browsers – can map the running JavaScript back to the source TypeScript file. This means that you can set the debugger breakpoints in your TypeScript file, and walk through your TypeScript file while debugging.

To debug our sample app, firstly get the index.html page running in Live Preview mode, and hit F12 to bring up the development tools. Chrome has a number of tools available for developers, including Network, Console, and Elements to inspect the DOM. Click on the Sources tab and hit Ctrl + P to open a file. Scroll down to app.ts, and hit Enter. Put a breakpoint on line 9 ( var myClass = new MyClass()), and then re-load the page.

Chrome should pause the page in debugger mode as follows:

Brackets debugging TypeScript using Chrome development tools.

You can now use all of the Chrome debugging tools to your heart's content.