{"id":1678,"date":"2016-08-30T16:12:07","date_gmt":"2016-08-30T16:12:07","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=725"},"modified":"2019-02-20T10:46:01","modified_gmt":"2019-02-20T17:46:01","slug":"announcing-typescript-2-0-rc-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-0-rc-2\/","title":{"rendered":"Announcing TypeScript 2.0 RC"},"content":{"rendered":"

TypeScript 2.0 is almost<\/em> out, and today we’re happy to show just how close we are with our release candidate! If you haven’t used TypeScript yet, check out the intro tutorial on our website<\/a> to get started.<\/p>\n

To start using the RC now, you can download TypeScript 2.0 RC for Visual Studio 2015<\/a> (which requires VS Update 3<\/a>), grab it through NuGet, or use npm:<\/p>\n

npm install -g typescript@rc\n<\/code><\/pre>\n
Visual Studio Code users can follow the steps here<\/a> to use the RC.<\/p>\n
This RC gives an idea of what the full version of 2.0 will look like, and we’re looking for broader feedback to stabilize and make 2.0 a solid release. Overall, the RC should be stable enough for general use, and we don’t expect any major new features to be added past this point.<\/p>\n
On the other hand, lots of stuff has been added since 2.0 beta was released, so here’s a few features that you might not have heard about since then.<\/p>\n
<\/a>Tagged Unions<\/h2>\n
Tagged unions are an exciting new feature that brings functionality from languages like F#, Swift, Rust, and others to JavaScript, while embracing the way that people write JavaScript today. This feature is also called discriminated unions<\/em>, disjoint unions<\/em>, or algebraic data types<\/em>. But what’s in the feature is much more interesting than what’s in the name.<\/p>\n
Let’s say you have two types: Circle<\/code> and Square<\/code>. You then have a union type of the two named Shape<\/code>.<\/p>\n
\n
interface<\/span> Circle<\/span> {\n    kind<\/span>: \"circle\"<\/span>;\n    radius<\/span>: number<\/span>;\n}\n\ninterface<\/span> Square<\/span> {\n    kind<\/span>: \"square\"<\/span>;\n    sideLength<\/span>: number<\/span>;\n}\n\ntype<\/span> Shape<\/span> = <\/span>Circle<\/span> |<\/span> Square<\/span>;<\/pre>\n<\/div>\n
Notice that both Circle<\/code> and Square<\/code> have a field named kind<\/code> which has a string literal type. That means the kind<\/code> field on a Circle<\/code> will always contain the string \"circle\"<\/code>. Each type has a common field, but has been tagged<\/em> with a unique value.<\/p>\n
In TypeScript 1.8, writing a function to get the area of a Shape<\/code> required a type assertions for each type in Shape<\/code>.<\/p>\n
\n
function<\/span> getArea<\/span>(shape<\/span>: Shape<\/span>) {\n    switch<\/span> (shape.kind) {\n        case<\/span> \"circle\"<\/span>:\n            \/\/ Convert from 'Shape' to 'Circle'<\/span>\n            let<\/span> c<\/span> = shape as<\/span> Circle<\/span>;\n            return<\/span> Math.PI *<\/span> c.radius **<\/span> 2<\/span>;\n\n        case<\/span> \"square\"<\/span>:\n            \/\/ Convert from 'Shape' to 'Square'<\/span>\n            let<\/span> sq<\/span> = shape as<\/span> Square<\/span>;\n            return<\/span> sq.sideLength **<\/span> 2<\/span>;\n    }\n}<\/pre>\n<\/div>\n
Notice we made up intermediate variables for shape<\/code> just to keep this a little cleaner.<\/p>\n
In 2.0, that isn’t necessary. The language understands<\/em> how to discriminate based on the kind<\/code> field, so you can cut down on the boilerplate.<\/p>\n
\n
function<\/span> getArea<\/span>(shape<\/span>: Shape<\/span>) {\n    switch<\/span> (shape.kind) {\n        case<\/span> \"circle\"<\/span>:\n            \/\/ 'shape' is a 'Circle' here.<\/span>\n            return<\/span> Math.PI *<\/span> shape.radius **<\/span> 2<\/span>;\n\n        case<\/span> \"square\"<\/span>:\n            \/\/ 'shape' is a 'Square' here.<\/span>\n            return<\/span> shape.sideLength **<\/span> 2<\/span>;\n    }\n}<\/pre>\n<\/div>\n
This is totally valid, and TypeScript can use control flow analysis to figure out the type at each branch. In fact, you can use --noImplicitReturns<\/code> and the upcoming --strictNullChecks<\/code> feature to make sure these checks are exhaustive.<\/p>\n
Tagged unions make it way easier to get type safety using JavaScript patterns you’d write today. For example, libraries like Redux will often use this pattern when processing actions.<\/p>\n
<\/a>More Literal Types<\/h2>\n
String literal types are a feature we showed off back in 1.8, and were tremendously useful. Like you saw above, we were able to leverage them to bring you tagged unions.<\/p>\n
We wanted to give some more love to types other than just string<\/code>. In 2.0, each unique boolean<\/code>, number<\/code>, and enum member will have its own type!<\/p>\n
\n
type<\/span> Digit<\/span> = <\/span>0<\/span> |<\/span> 1<\/span> |<\/span> 2<\/span> |<\/span> 3<\/span> |<\/span> 4<\/span> |<\/span> 5<\/span> |<\/span> 6<\/span> |<\/span> 7<\/span> |<\/span> 8<\/span> |<\/span> 9<\/span>;\nlet<\/span> nums<\/span>: Digit<\/span>[] =<\/span> [1<\/span>, 2<\/span>, 4<\/span>, 8<\/span>];\n\n\/\/ Error! '16' isn't a 'Digit'!<\/span>\nnums.push(16<\/span>);<\/pre>\n<\/div>\n
Using tagged unions, we can express some things a little more naturally.<\/p>\n
\n
interface<\/span> Success<\/span><T<\/span>> {\n    success<\/span>: true<\/span>;\n    value<\/span>: T<\/span>;\n}\n\ninterface<\/span> Failure<\/span> {\n    success<\/span>: false<\/span>;\n    reason<\/span>: string<\/span>;\n}\n\ntype<\/span> Result<\/span><T<\/span>> = <\/span>Success<\/span><T<\/span>> |<\/span> Failure<\/span>;<\/pre>\n<\/div>\n
The Result<T><\/code> type here represents something that can potentially fail. If it succeeds, it has a value<\/code>, and if it fails, it contains a reason for failure. The value<\/code> field can only be used when success<\/code> is true<\/code>.<\/p>\n
\n
declare<\/span> function<\/span> tryGetNumUsers<\/span>(): Result<\/span><number<\/span>>;\n\nlet<\/span> result<\/span> = tryGetNumUsers();\nif<\/span> (result.success ===<\/span> true<\/span>) {\n    \/\/ 'result' has type 'Success<number>'<\/span>\n    console.log(`Server reported <\/span>${<\/span>result.value}<\/span> users`<\/span>);\n}\nelse<\/span> {\n    \/\/ 'result' has type 'Failure'<\/span>\n    console.error(\"Error fetching number of users!\"<\/span>, result.reason);\n}<\/pre>\n<\/div>\n
You may’ve noticed that enum members get their own type too!<\/p>\n
\n
enum<\/span> ActionType<\/span> { Append, Erase }\n\ninterface<\/span> AppendAction<\/span> { \n    type<\/span>: ActionType.Append;\n    text<\/span>: string<\/span>;\n}\n\ninterface<\/span> EraseAction<\/span> {\n    type<\/span>: ActionType.Erase;\n    numChars<\/span>: number<\/span>;\n}\n\nfunction<\/span> updateText<\/span>(currentText<\/span>: string<\/span>, action<\/span>: AppendAction<\/span> |<\/span> EraseAction<\/span>) {\n    if<\/span> (action.type ===<\/span> ActionType.Append) {\n        \/\/ 'action' has type 'AppendAction'<\/span>\n        return<\/span> currentText +<\/span> action.text;\n    }\n    else<\/span> {\n        \/\/ 'action' has type 'EraseAction'<\/span>\n        return<\/span> currentText.slice(0<\/span>, -<\/span>action.numChars);\n    }\n}<\/pre>\n<\/div>\n
<\/a>Globs, Includes, and Excludes<\/h2>\n
When we first introduced the tsconfig.json<\/code> file, you told us that manually listing files was a pain. TypeScript 1.6 introduced the exclude<\/code> field to alleviate this; however, the consensus has been that this was just not enough. It’s a pain to write out every single file path, and you can run into issues when you forget to exclude new files.<\/p>\n
TypeScript 2.0 finally adds support for globs. Globs allow us to write out wildcards for paths, making them as granular as you need without being tedious to write.<\/p>\n
You can use them in the new include<\/code> field as well as the existing exclude<\/code> field. As an example, let’s take a look at this tsconfig.json<\/code> that compiles all our code except for our tests:<\/p>\n
\n
{\n    \"<\/span>include\"<\/span><\/span>: [\n        \"<\/span>.\/src\/**\/*.ts\"<\/span><\/span>\n    ],\n    \"<\/span>exclude\"<\/span><\/span>: [\n        \"<\/span>.\/src\/tests\/**\"<\/span><\/span>\n    ]\n}<\/pre>\n<\/div>\n
TypeScript’s globs support the following wildcards:<\/p>\n