We are excited to see the feedback and interest in all the new features that we’ve released with TypeScript 0.9. We’re already seeing users converting hundreds of thousands of lines to the new version and using the new features in earnest.
Today, we’re releasing an update that addresses a few of the highest priority issues that have been raised so far by users moving to the 0.9.0 release. This update covers incorrect codegen with getters, poor errors with non-UTF-8 files, incorrect type inference, and more.
We appreciate your feedback. It’s helped make TypeScript a stronger, richer tool. We encourage you to update to the 0.9.0.1 release and let us know what you think.
Today, we’re excited to be releasing TypeScript 0.9.0. This release represents the largest update to TypeScript to date, bringing significant changes to the language, compiler and tools. These span from highly requested new language features like Generics, to a new compiler infrastructure that lays the foundation for TypeScript tools scalability, to hundreds of bug fixes and general improvements.
TypeScript, since its release in October last year, has helped teams write large applications for the web, server, and Windows desktop. TypeScript's lightweight type system is proving itself to be an effective way of providing tooling and early error detection that makes programming these large applications easier and safer than before.
This release marks the first step of the 0.9.x series, introducing most of the new capabilities of this series which will be further refined over the next few months based on your feedback. With today’s release, we’ve made a big step forward on the road to TypeScript 1.0.
Check out the downloads page to take TypeScript 0.9 for a spin today, take a look at the breaking changes list for help moving code forward to the new compiler, and send us your feedback on typescript.codeplex.com.
TypeScript 0.9 addresses many of the most highly requested language asks we’ve heard over the last 8 months. Many of these improvements are targeted at furthering TypeScript’s commitment to enabling accurate and faithful descriptions of JavaScript API patterns. Through community projects like DefinitelyTyped, we’ve seen a great ecosystem of library typings emerge, which has helped identify where the language changes could be most valuable.
Complete details of the TypeScript 0.9 language are available in the TypeScript specification. Highlights include:
The most highly requested feature by 0.8 users, generics enable capturing relationships between inputs and outputs in APIs, enabling richer type checking for better error reporting and tools. For example, generics allow the typing of the Array#map function from JavaScript to relate the element type of the array with the parameter to the callback function (‘T’ below), and the return type of the callback function with the return type of ‘map’ (‘U’ below).
interface Array<T> { // ... map<U>(callbackfn: (value: T, index: number, array: T[]) => U): U[]; // ... } var array: Array<string> = ["John", "Sam", "George"]; var lengths = array.map((val, idx, arr) => val.length);
In many cases, the type arguments can be inferred, as in the call to array.map above.
Many JavaScript APIs use strings parameters whose values determine the type returned by the API. Overloading on constants enables TypeScript to capture this pattern and others like it.
interface Document { createElement(tagName: string): HTMLElement; createElement(tagName: 'canvas'): HTMLCanvasElement; createElement(tagName: 'div'): HTMLDivElement; createElement(tagName: 'span'): HTMLSpanElement; // + 100 more }
The 0.9 release uses this technique to give more accurate type information for DOM functions like createElement, getElementsByTagName, addEventListener, and more.
TypeScript has built-in language support for external module loaders like CommonJS and AMD, which enables TypeScript to be used in environments like Node.js on the desktop and with libraries like require.js in the browser. Both of these module systems provide the ability to provide an explicit value for the module. For example, a ‘Client’ class may be set as the exported value from a module, allowing the ‘import’ to directly import the class. TypeScript 0.9 now includes “export =” to support this use case
// client.ts class Client { constructor(public name: string, public description: string) { } } export = Client; // app.ts import MyClient = require('./client'); var myClient = new MyClient("Joe Smith", "My #1 client");
TypeScript 0.9 includes a finalized design for enums, offering a typed way to work with finite collections of constant numeric values.
enum Color { red, blue, green } var myColor = Color.red; console.log(Color[myColor]);
Enums also allow converting to and from string representations, by indexing into the enum, as shown using Color[myColor] in the above example.
Using declaration merging in TypeScript 0.9, you can now grow the static-side of a class or expand a function value with new properties by following each with a module definition of the same name. This makes it possible to express API patterns like nested classes, functions with static properties and more.
function readInput(separator = readInput.defaultSeparator) { // read input } module readInput { export var defaultSeparator = ":"; }
This release includes a significantly re-engineered compiler, which lays the foundation for great tooling scalability going forward, and provides a much higher fidelity implementation of the TypeScript language specification.
The new compiler addresses over 150 issues reported on CodePlex since the 0.8 release. These include places where the compiler now catches potential errors more reliably, more accurate tools, and general improvements across the board.
The new compiler has been designed to enable better incremental performance while editing code in IDEs (completion lists, error reporting, hover type information, etc.). This is important to ensure that TypeScript IDEs can scale up to the 100k+ line of code codebases that we are already seeing be written in TypeScript today. The 0.9 release marks the first big step with this new compiler architecture. Already, 0.9 offers markedly improved editing performance for large codebases, and we expect this to continue to increase significantly as we further tune the new compiler.
One temporary impact of these changes is that command line compiler compilation with 0.9 is somewhat slower than 0.8. We expect to see significant improvements here in 0.9.1.
Check out TypeScript 0.9 today, watch the discussion video on Channel 9, and send us feedback at typescript.codeplex.com.
Today we’re making an early preview available which showcases some of the new features coming in 0.9.0 preview release. It’s intended for users who wish to try out these features, begin porting existing applications, and who don’t mind a few rough edges in the compiler and language service along the way. Users who wish to stay on stable builds may wish to skip this early preview and wait for the 0.9.0 preview release (or grab the current 0.8.3.1 preview release).
The 0.9 series marks a major milestone on the way to our 1.0 release. This series brings major changes to the TypeScript language, compiler, and language services. With it, the language now supports generics, the top-most requested feature, along with improvements to the type system. In addition, the compiler and language service have been rewritten, largely from scratch, to work better with large projects in an interactive environment, which allows working with projects of more than 100k lines with little to no slowdown.
Many users have requested the ability to try 0.9 during its development. Up to this point, the best way to try it was to use the command-line based compiler by checking out the ‘develop’ branch, but because of the incompatibilities between the 0.8 and 0.9 language services there was no way to use the techniques mentioned in a previous blog post, leaving users of Visual Studio without a way to also try out 0.9.
The early previews are snapshots of the Visual Studio plugin that are compatible with the latest language service APIs in the 0.9 work. The intent is to unblock users who wish to stay up-to-date and continue to explore 0.9 features as they’re created.
By default, the first early preview contains a snapshot of the ‘develop’ branch called ‘release-0.9.0-alpha’ and can be installed just like our previous preview releases. This snapshot features generics and overloading-on-constants. We’re continuing to add new features and polish the implementation, so to keep up-to-date, you will need to update your compiler and language service from the ‘develop’ branch. We’ve written about how to do this in a blog post.
Because the early previews are snapshots of our current work-in-progress, not all functionality from 0.8.3 has been ported to the new architecture. Features known to not be complete in the first early preview, or are known missing:
Due to the deep changes in the language and compiler, there are some incompatibilities between the 0.9 series and the last preview release, 0.8.3. Some of these changes come from tightening the compiler to align more closely with the specification. Others are breaking changes made to improve the overall TypeScript experience in the long run. For the list of breaking changes between the 0.8.x series and the 0.9 series, see the wiki page.
We’re continuing to push toward the 0.9 release, and we hope this early preview provides an opportunity to get some additional feedback on new and changed features. For those who aren’t afraid to dive in to a work-in-progress, we hope this gives you the chance to help us make TypeScript a better, richer, project.
We've released a hotfix to the 0.8.3 TypeScript for Visual Studio 2012 plugin. The 0.8.3 preview release included a broad range of improvements to the TypeScript experience, but it also included an issue that caused editor performance to degrade significantly in some cases. The hotfix release (0.8.3.1) addresses this issue and can be found here.
The upcoming TypeScript 0.9 release will represent the most significant changes to TypeScript since the first public release last October, bringing highly requested new language features as well as a significant re-design of the TypeScript compiler. In this post, we’ll give a first quick look at a few of the top investments for the 0.9 release. Stay tuned for further updates in the coming weeks.
Generics has been the most highly requested feature over the last 6 month, and has always been something we planned to include in TypeScript 1.0.
To understand why this feature seems to be so important, it’s useful to first recognize that many common JavaScript APIs really are already generic. The simplest examples are the Array methods in the ECMAScript 5 core libraries. Take for example this use of the Array#map method:
var lengthOfSecond = ["a", "bb", "ccc"].map(x => x.length)[1];
The ‘map’ method is generic – it can operate on any kind of array, and the kind of array it returns is based on the return type of the callback function it is passed.
Today, these relationships aren’t fully captured in the type of Array#map, and TypeScript infers the ‘lengthOfSecond’ variable above to be ‘any’. If these relationships were part of the type of the Array#map method, TypeScript would be able to infer that the type of ‘lengthOfSecond’ is ‘number’ in the example above without any further type annotation, leading to better tooling and static analysis without any extra work by the author of this code.
It turns out that arrays were special-cased in TypeScript 0.8 to enable part of this to be expressed, but that mechanism wasn’t made available to other libraries that do similar things, like underscore.js, d3, and others.
In TypeScript 0.9, generics will allow us to capture the true intended typing of these libraries.
interface Array<T> { // ... map<U>(callbackfn: (value: T, index: number, array: T[]) => U): U[]; // ... }
Another example is knockout.js. Knockout has a notion of observables, which can be created over any type of value and used for databinding and change notification. A simple piece of code might look like:
var person = { name: ko.observable("Bob"), age: ko.observabel(37) } var x = person.name().length + person.age(); person.name("Robert");
Here ko.observable is a function which takes some type T and returns an Observable<T> which is a function that can be called with no arguments to get the value of type T, or called with one argument of type T to set the value. Without generics, we would have to say that the get and set functionality produce ‘any’. But with generics, we can capture the intended API shape:
module ko { export interface Observable<T> { (): T; (value: T): any; } export function observable<T>(value: T): Observable<T>; }
These examples give a sense of what we expect generics to look like in TypeScript. Here’s a few other design principles that have guided the way we’ve been thinking about generics so far:
For full details, check out the current draft spec in the ‘develop’ branch on typescript.codeplex.com, and stop by the forums for any thoughts, feedback, questions or discussion.
A very common pattern in JavaScript APIs is to take a string parameter whose value implies something about the type that will be returned. Examples include the ‘createElement’ method in the DOM:
var canv = document.createElement('canvas'); canv.getContext('2d');
Because we passed the string ‘canvas’, this API will return a HTMLCanvasElement, which will allow us to call ‘getContext’. In TypeScript 0.8, the code above would have required an additional cast though, because the connection between ‘canvas’ and HTMLCanvasElement wasn’t available to the TypeScript compiler.
Overload on constants is a TypeScript 0.9 feature which allows functions taking strings to have additional overloaded signatures that take specific string constants as parameters, and may have more specific types elsewhere in the signature. For ‘createElement’, this might look like:
If you call this function with a string literal argument, you’ll get the more specific type. If you call it with a string expression other than a literal value (i.e. an identifier, the result of a function call, etc.) you’ll get the default ‘HTMLElement’.
Even straightforward cases like ‘createElement’ are fairly common in JavaScript, but there are some more interesting cases where this feature comes in handy. Take for example the ‘addEventListener’ pattern in DOM (or similar ‘on’ pattern in node.js):
document.addEventListener('mousemove', ev => { ev.clientX; });
In TypeScript 0.8, the type of ‘ev’ would be inferred to be ‘Event’, and the code above would report an error because the ‘clientX’ property doesn’t exist on all ‘Event’s. But the ‘mousemove’ event will always provide a ‘MouseEvent’ argument, so there is an association between ‘mousemove’ as the first parameter to addEventListener, and the parameter type of the callback that is the second parameter to addEventListener.
interface EventTarget { addEventListener(type: string, listener: (evt: Event) => void): void; addEventListener(type: 'mousemove', listener: (evt: MouseEvent) => void): void; addEventListener(type: 'mouseup', listener: (evt: MouseEvent) => void): void; addEventListener(type: 'blur', listener: (evt: FocusEvent) => void): void; // + 100 more }
Along with the new language work, TypeScript 0.9 brings a new compiler architecture designed to better handle scaling up to the very large (100kloc and beyond) projects that we’ve seen TypeScript applied to over the last 6 months. To provide rich interactive tooling over projects of this size, the TypeScript compiler needs to be able to do only a relatively small amount of new work when a change is made to the source code.
To accomplish this, we’ve been working on a couple of foundational changes to the TypeScript compiler:
This work is also helping with language correctness, bringing the compiler more fully in line with the language specification.
Work is well underway on all of these features and many more for 0.9.0. Because this release will include a compiler with many significant changes, we’re hoping to get out an early alpha preview for early adopters to take for a spin in the next month or so. Until then, check out the spec drafts in the ‘develop’ branch, join us in the forums, and track progress at typescript.codeplex.com.
Today, we're happy to announce the 0.8.3 preview release of TypeScript. This release adds incremental polish and bugfixes to the TypeScript compiler, language service, and Visual Studio plugin.
In the 0.8.3 preview release, we fixed a few key issues that improve compiler correctness and performance, including issues with 'this' typing, external modules, and scoping. The 0.8.3 preview also includes improvements to IO buffering which should now allow large projects to compile much more quickly when compiled using Node as the JavaScript host.
The Visual Studio support for source level debugging of TypeScript no longer requires that the files being debugged are part of the current project. This allows Visual Studio to attach to a running instance of Internet Explorer and debug TypeScript projects remotely. To do so, attach to the running IE instance which has the Script type, with "Attach to:" set to Script code.
After you attach to a running web application, you will see the associated files show up in the Script Documents in the Solution Explorer:
This will let you open the associated TypeScript files and debug using them directly.
In this preview release, the quick info now shows a much more complete picture of the symbol being hovered. The info during hover now includes the kind of symbol and the symbol's name in addition to the type. Additionally, hover information is now more uniform, and in some cases even more concise, letting developers focus on the necessary information about each symbol.
While we've been finishing up the 0.8 train with this release, work is already underway on the upcoming 0.9 preview release. The 0.9 preview release will include some of the larger language updates and commonly requested features. More details coming soon.
Starting with release 0.8.2.0, you can now update the TypeScript language services file, the compiled JavaScript that powers most of the TypeScript editor features in Visual Studio. This includes tasks like error reporting, compile-on-save, renaming, go to definition, completion lists, signature help, and others.
By updating your TypeScript language services file, you can try out the latest features we're working on before they appear in an official release. Naturally, you might encounter bugs here as the code built in the development branches isn't as stable or well-tested as the released version.
The majority of the TypeScript editor features are found in a file called typescriptSerivces.js. To update your file, you'll need to get a new copy and overwrite the existing copy.
The LKG ("Last Known Good") version of the compiler is updated somewhat frequently. You can get a copy from CodePlex using the source browser and downloading the typescriptServices.js file from the bin directory.
You'll need some basic tools first
> git clone https://git01.codeplex.com/typescript
This will set up a TypeScript repository in a subfolder of the current folder called 'typescript'.
> cd typescript > git checkout develop
If you're interested in the latest, the develop branch is probably your best bet. There may be other branches with active development; if you know of a branch you'd like to try out instead, replace develop with that branch name.
> npm install
This will install a local copy of jake, the build system we use for TypeScript.
> .\node_modules\.bin\jake local
This will produce built\local\typescriptServices.js. Copy that file as indicated below.
If you like, you can simply delete the TypeScript folder created in the first step and be done. However, if you come back at a later time and want a new fresh copy (with the latest changes), you'll need to run git pull to get the newest sources. After that, just run jake local and copy over the typeScriptServices.js file again.
You'll need to locate the folder where the TypeScript extension was installed. Look for a file called typescriptServices.js in a folder like:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\enn4wcm5.z2b\
The highlighted portion at the end there will be different on every machine, but there shouldn't be too many of them in the Extensions folder. In some rare cases, you might have more than one subfolder that has a TypeScript installation in it; if this is the case, you'll want to use the newest one (check the Created date).
When you find the one with typescriptServices.js, backup that file and copy in the new version. After you restart Visual Studio, you'll be working with the updated services file.
When we talk about a type in TypeScript, we mean a collection of things that you can do with a variable (or expression). You might be able to read or write a given property, call a function, use the expression as a constructor, or index into the object. Some objects (like Date) in JavaScript can do nearly all of those! In TypeScript, interfaces are the most flexible way of describing types.
You'll see interfaces used to describe existing JavaScript APIs, create shorthand names for commonly-used types, constrain class implementations, describe array types, and more. While they don't generate any code (and thus have no runtime cost!), they are often the key point of contact between any two pieces of TypeScript code, especially when working with existing JavaScript code or built-in JavaScript objects.
The only job of an interface in TypeScript is to describe a type. While class and function deal with implementation, interface helps us keep our programs error-free by providing information about the shape of the data we work with. Because the type information is erased from a TypeScript program during compilation, we can freely add type data using interfaces without worrying about the runtime overhead.
While that sounds like a simple, one-purpose task, interfaces role in describing types becomes manifest in a large variety of ways. Let's look at some of them and how they can be used in TypeScript programs.
To define an interface in TypeScript, use the interface keyword:
interface Greetable { greet(message: string): void;}
This defines a type, Greetable, that has a member function called greet that takes a string argument. You can use this type in all the usual positions; for example in a parameter type annotation. Here we use that type annotation to get type safety on the g parameter:
function helloEnglish(g: Greetable) { g.greet('Hello there!'); // OK g.greet(42); // Not OK -- 42 is not a string g.greep('Hi'); // Not OK -- 'greep' is not a member of 'Greetable'}
When this code compiles, you won't see any mention of Greetable in the JavaScript code. Interfaces are only a compile-time construct and have no effect on the generated code.
Interfaces get to play a lot of roles in TypeScript code. We'll go into more detail on these after a quick overview.
Many JavaScript functions take a "settings object". For example, jQuery's $.ajax takes an object that can have up to several dozen members that control its behavior, but you're only likely to pass a few of those in any given instance. TypeScript interfaces allow optional properties to help you use these sorts of objects correctly.
JavaScript freely mixes members (foo.x) with indexers (foo['x']), but most programmers use one or the other as a semantic hint about what kind of access is taking place. TypeScript interfaces can be used to represent what the expected type of an indexing operation is.
Often, you'll want to make sure that a class you're writing matches some existing surface area. This is how interfaces are used in more traditional OOP languages like C# and Java, and we'll see that TypeScript interfaces behave very similarly when used in this role.
Interfaces normally describe the shape of an instance of a class, but we can also use them to describe the static shape of the class (including its constructor function). We'll cover this in a later post.
You can also use interfaces to define the shape of objects that will typically be expressed in an object literal. Here's an example:
interface ButtonSettings { text: string; size?: { width: number; height: number; }; color?: string;}function createButton(settings: ButtonSettings) { ... }
Note the use of the ? symbol after some of the names. This marks a member as being optional. This lets callers of createButton supply only the members they care about, while maintaining the constraint that the required parts of the object are present:
createButton({ text: 'Submit' }); // OKcreateButton({ text: 'Submit', size: { width: 70, height: 30 }}); // OKcreateButton({ text: 'Submit', color: 43); // Not OK: 43 isn't a stringcreateButton({ text: 'Submit', size: { width: 70 }); // Not OK: size needs a height as wellcreateButton({ color: 'Blue'}); // Not OK: 'text' member is required
You typically won't use optional members when defining interfaces that are going to be implemented by classes.
Here's another example that shows an interesting feature of types in TypeScript:
interface Point { x: number; y: number;}function getQuadrant(pt: Point) { ... }var pt = { x: 0, y: -1 };getQuadrant(pt); // OK: pt has members x and y of type number
Note that we didn't annotate pt in any way to indicate that it's of type Point. We don't need to, because type checking in TypeScript is structural: types are considered identical if they have the same surface area. Because pt has at least the same members as Point, it's suitable for use wherever a Point is expected.
Interfaces are also used to describe code that is present at runtime, but not implemented in the current TypeScript project. For example, if you open the lib.d.ts file that all TypeScript projects implicitly reference, you'll see an interface declaration for Number:
interface Number { toString(radix?: number): string; toFixed(fractionDigits?: number): string; toExponential(fractionDigits?: number): string; toPrecision(precision: number): string;}
Now if we have an expression of type Number, the compiler knows that it's valid to call toPrecision on that expression.
Moreover, interfaces in TypeScript are open, meaning you can add your own members to an interface by simply writing another interface block. If you have an external script that adds members to Date, for example, you simply need to write interface Date { /*...*/ } and declare the additional members.*
* Note: There are some known issues with the Visual Studio editor that currently prevent this scenario from working as intended. We'll be fixing this limitation in a later release.
A common pattern in JavaScript is to use an object (e.g. {}) as way to map from a set of strings to a set of values. When those values are of the same type, you can use an interface to describe that indexing into an object always produces values of a certain type (in this case, Widget).
interface WidgetMap { [name: string]: Widget;}var map: WidgetMap = {};map['gear'] = new GearWidget();var w = map['gear']; // w is inferred to type Widget
Let's extend the Greetable example above:
/** Represents an object that can be greeted */interface Greetable { /** Used to welcome someone */ greet(message: string): void; /** The preferred language of this object */ language: string;}
We can implement this interface in a class using the implements keyword:
class Person implements Greetable { language = 'English'; greet(message: string) { console.log(message); }}
Now we can use an instance of Person wherever a Greetable is expected:
var g: Greetable = new Person();
Similarly, we can take advantage of the structural typing of TypeScript to implement Greetable in an object literal:
var greeter = { greet: (message: string) => { console.log(message) }; language: 'Any';};
We’re happy to announce the 0.8.2 preview release of TypeScript. This release has been focused on addressing key usability feedback and filling in tooling experiences. Along the way, we’ve also incorporated some of the highest-rated feature requests and bugfixes.
Being able to see API documentation comments during Intellisense and parameter help has been a highly requested feature. In fact, it’s currently the 2nd most-requested feature in the issue tracker.
With 0.8.2, the TypeScript compiler and tools now support JSDoc comments.
In the TypeScript implementation, because types are already part of the system, we allow the JSDoc type annotation to be elided, as in the example above.
You can now document a variety of language constructs (including classes, modules, interfaces, and functions) with comments that become part of the information displayed to the user. We’ve also started extending lib.d.ts, the default JS and DOM API library, with JSDoc comments.
This capability is also part of the language service, so cross-platform tools can take advantage of it.
Many of the themes in this release center around simplifying workflow. We’ve focused on a few key areas with the aim of streamlining developing in TypeScript.
Languages like TypeScript which compile to JavaScript add a build step into the development cycle. Enabling a compile-on-save mode of use minimizes this overhead by automatically updating the compiled JS when the TypeScript source changes. With 0.8.2, we’ve done work to further enable this in both the NPM-based compiler and in Visual Studio.
The 0.8.2 release adds initial support for compile-on-save in Visual Studio. Just as the name implies, when enabled the project or file being edited will be compiled when the changes are saved. For more information, please see the wiki page for compile-on-save.
TypeScript supports compile-on-save on the command line using the cross-platform NPM-based TypeScript compiler as well with the improved --watch compiler option. This option allows a compile to begin watching a set of files. Once a watched file is changed, the compiler rebuilds the corresponding output for that file.
We’ve recently branched for the upcoming 0.8.2 release of TypeScript. Before we talk about what’s new, we wanted to talk a bit about the engineering process that goes into making a release.
Going forward, TypeScript development will happen across three types of branches. Our current two branches of 'master' and 'develop' stay, taking the roles of stable and cutting edge development as before. We're also going to be adding branches for each of the upcoming releases, so that they each release can stabilize. The current 0.8.2 release is wrapping up, and you can watch the stabilization process by going to the CodePlex repo and selecting "release-0.8.2" in the dropdown. For more information, there's also a wiki page with more details about the separate branches.
We’re currently working on the 0.8.x release train, which is focused on addressing key usability feedback and filling in tools experience. In parallel, design work on the upcoming 0.9.x release train is underway, in which we expect to address some of the larger TypeScript language changes that are under discussion on the TypeScript forums and issue tracker. More details on early 0.9.x design thinking coming in a future post.
The 0.8.2 release will include, among other features and bug fixes, these popular requests:
As always, you can follow the work on CodePlex, and share any feedback on the forums and issue tracker.
Since releasing TypeScript 0.8.1 a few weeks ago, we have heard a few reports of issues blocking the usage of source-map based debugging. To address these, today, we’ve made available TypeScript 0.8.1.1, a bugfix release of 0.8.1. This preview focuses on further refining the debugging experience and addressing rough edges in our initial support for source maps in Visual Studio. Users of the Visual Studio plugin in particular are recommended to upgrade from 0.8.1 to 0.8.1.1.
The version 0.8.1.1 preview is available for Visual Studio, npm, and source.
Congratulations to Fuse Labs on releasing the new version of Socl! Fuse Labs was an early supporter of TypeScript, and they played a key role in helping to shape TypeScript into a language for web development at scale. It's been great to see So.cl grow and use TypeScript to rapidly prototype and build the new site.
When you're done reading about it, be sure to give the new Socl a spin!
We released the first public preview of TypeScript last month, and have been excited to see the great reaction from the developer community. Since the preview, we’ve seen an influx of suggestions and bug reports, integration into various build and testing tools, and declare files for a variety of existing JavaScript libraries.
Today, we’re happy to announce the second publically available preview of TypeScript: version 0.8.1. This preview focuses on addressing critical bugs and adding one of the most requested features: source level debugging.
Debugging
TypeScript now supports source level debugging! The source map format has been gaining popularity as a way of debugging languages which translate to JavaScript and is supported by a variety of browsers and tools. With version 0.8.1, the TypeScript compiler officially supports source maps. Additionally, the new version of TypeScript for Visual Studio 2012 supports debugging using the source map format.
From the command-line, we now fully support the use of the --sourcemap flag, which outputs a source map file corresponding to the JavaScript output. This file will allow directly debugging the original TypeScript source in source map-enabled browsers and Visual Studio.
To enable debugging in Visual Studio select ‘Debug’ from the dropdown after creating an HTML Application with TypeScript project.
Once selected, you can set breakpoints and step directly in your TypeScript code.
You can also see your current location using the call stack.
Bug Fixes
This release addresses many issues found in our first public preview. These fixes have improved compiler stability, compiler correctness, and UTF-8 support. A big “thank you!” to everyone who has helped so far by reporting bugs and participating in the issue tracker and forums.
Breaking Changes
There are two known breaking changes since v0.8.0:
Conclusion
The version 0.8.1 preview is now available for Visual Studio, npm, and source. We’re excited to see how people will continue using, building upon, and integrating TypeScript into their JavaScript development, and we’d love to get your feedback.