Practical .NET

TypeScript & Visual Studio 2013: Coming of Age

Visual Studio 2013, with the latest version of TypeScript, gives you the same kind of support you've come to expect when writing code in C# and Visual Basic.

• By Peter Vogel
• 02/20/2014

I'm sure somewhere, someone is using F# or one of the other "non-traditional" .NET languages in a production system. But those languages never seem to attract the user base of the "traditional" .NET languages, C# and Visual Basic…with one exception: TypeScript.

TypeScript, while still in beta, already has a rich ecosystem of support and, according to the TypeScript blog millions of lines of code "in the wild." I have to say those people with TypeScript code in production are braver than I am -- I'm not a "go live license" kind of guy. But, having said that, I'm developing a major application for a client using TypeScript, and it will be released as soon as the language comes out of beta.

In my Practical JavaScript column, I've been using TypeScript in Visual Studio 2012, coupled with various add-ins (including Mads Kristensen's Web Essentials). The support I get while writing code with these tools has been acceptable enough to build an application with it. In Visual Studio 2013 the support for TypeScript goes beyond to acceptable to satisfy almost all expectations a developer could have for a first-class, server-side language (even if the code is running on the client).

Interestingly, Visual Studio 2013 doesn't completely support TypeScript "out of the box." Visual Studio 2013 comes not with TypeScript, but with an "Install the Latest TypeScript for Visual Studio" project template. Opening that project takes you to a site where you can download and install the current version of TypeScript (as I write this, that current version is TypeScript 0.9.5). Reusing that link should upgrade your TypeScript support as TypeScript moves toward version 1.0. There's also a TypeScript project template that generates an HTML "Hello, World" project, but I can't imagine why you'd use it. Typically, you'll be adding TypeScript files to ASP.NET projects.

For older versions of Visual Studio, you can also download the latest version of the language from the TypeScript site. And, while this column discusses TypeScript support in Visual Studio 2013, TypeScript support extends to other IDEs (part of the rich eco-system that I mentioned) and much of what I describe here might also work in Visual Studio 2012 -- I just didn't test it.

Supporting TypeScript Developers
TypeScript does in Visual Studio 2013 what it does in the other versions of Visual Studio: It gives you IntelliSense support and compile-time checking of your code in the way a C# or Visual Basic developer would expect. That support also includes checking your code's integration with other JavaScript libraries (such as jQuery, Knockout, Breeze and so on) through the TypeScript equivalent of a type library: A definition file with the extension .d.ts. You can find definition files for almost every JavaScript library in the world on the DefinitelyTyped site, but the files are most easily retrieved through NuGet.

One big change in Visual Studio 2013 is that, in the same way C# or Visual Basic files know all about the other classes in the same project, TypeScript files automatically pick up the definitions of any TypeScript classes in the same project. This is a real step forward: In previous versions of Visual Studio, odd little comments were required to tie TypeScript files together (you can add those "comment references" just by dragging TypeScript files from Solution Explorer and dropping them into your TypeScript code file).

The second big change for TypeScript developers in Visual Studio 2013 is debugging support. You can set breakpoints in your TypeScript code, and when your JavaScript code executes in the browser, you'll be stepped through the TypeScript code that generated the JavaScript code. In break mode you can examine variables, change values, and do all the things you expect to do in a server-side language. In fact, if you put a breakpoint in your generated JavaScript code, you'll find yourself in your original TypeScript code when the breakpoint is hit. That debugging support is provided through two files: a .js.map file that ties your TypeScript code to the generated JavaScript code, and a comment at the bottom of your generated JavaScript file that refers to the map file.

Beyond those major changes, there are some little changes to make life easier when you're using TypeScript. You can now add a TypeScript file to your project just by right-clicking on your project and selecting Add | TypeScript file. Adding a TypeScript file to a project causes Visual Studio to configure that project for TypeScript and also causes Visual Studio to offer to open NuGet Manager with a list of packages tagged with "typescript." This gives you your first chance to add the definition files for any JavaScript libraries your TypeScript code might need. There's also now a Properties Page for setting options on the compiler including the level of JavaScript to which you want to compile and whether to combine all of the output files into a single JavaScript file.

In Solution Explorer, the JavaScript files generated from a TypeScript file are no longer nested underneath the TypeScript file in Visual Studio 2013. This facilitates dragging those JavaScript files into the Web pages that need them. However, the files are also not visible at all until you turn on Show All Files.

What's Missing
Working with TypeScript in Visual Studio 2013 also led me to a "You don't miss the water until the well runs dry" moment: I've been missing Object Browser when working with TypeScript, without quite realizing it. As the number of classes in my TypeScript code increases, I've been using IntelliSense in place of Object Browser by typing in random items just to see what shows up in the IntelliSense dropdown lists. There's room out here for a "TypeScript Object Browser."

TypeScript debugging support has an interesting "feature": When I'm stepping through TypeScript code and I call a method in a JavaScript library, the debugger drops me into the JavaScript code in that library. That's a jarring context shift to me (I have enough problems debugging my code -- I'm fundamentally uninterested in debugging someone else's). It would be convenient if the debugger would default to stepping over calls to those libraries in the same way that it steps over calls to methods on .NET classes. Having said that, I can't imagine how that could be implemented (after all, I will need to step into JavaScript code that I will still, occasionally, write).

Upgrading to TypeScript 0.9.5 wasn't an unalloyed blessing. In earlier versions of Visual Studio I've been using Matthew Manela's Chutzpah add-in to do test-driven development (TDD) with TypeScript. While I was able to install Chutzpah through Tools | Extensions and Updates, I wasn't able to run my tests. I couldn't, for instance, persuade Visual Studio Test to generate JavaScript from my TypeScript files in a Visual Studio Test project (though I would get IntelliSense support and compile-time errors flagged in the code). Putting my TypeScript tests in my ASP.NET project rather than a separate Test project did cause my JavaScript files to be generated. However, my tests weren't found by Test Explorer (no surprise there in an ASP.NET project). Right-clicking on these files and selecting the Chutzpah Run JS Test option generated spurious compile-time errors.

And, because Visual Studio now searches out all TypeScript definition files, it found the three definition files for the Breeze JavaScript libraries (for versions 1.0, 1.2, and 1.4). Until I deleted the 1.0 and 1.2 version definition files, I got about 300 "duplicate reference" errors. Deleting the two extra definition files didn't solve my problems, though: the version 1.4 definition file isn't compatible with TypeScript 0.9.5.

This is the price I pay for working with beta software. But these are all temporary problems (and may well have been resolved by the time you read this).

Overall, TypeScript gives you the support you expect from a first-class language. It's missing just two things, really: An equivalent to Object Browser and native TDD support. But still, I'm happy. As client-side development continues to become more complex, you're going to need this language. Personally, I'm in love both with TypeScript and the support for it in Visual Studio 2013. I just want more.