{"id":1145,"date":"2017-08-31T16:44:32","date_gmt":"2017-08-31T16:44:32","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1145"},"modified":"2019-02-20T10:45:48","modified_gmt":"2019-02-20T17:45:48","slug":"announcing-typescript-2-5","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-5\/","title":{"rendered":"Announcing TypeScript 2.5"},"content":{"rendered":"
\nToday we’re happy to bring you TypeScript 2.5! If you’ve read\u00a0<\/span>our RC announcement<\/a>, we’ve got a few new items that we’re proud to highlight!<\/p>\n

If you’re not familiar with TypeScript, it’s a typed superset of JavaScript. More simply put, it’s just JavaScript with optional static types. Static types can make it easier to maintain your code by catching bugs early on, making it easier to navigate your projects, giving accurate code completion, and providing handy fixes for when you do make mistakes. By making types optional, you can get the flexibility of plain JavaScript when you need it, all while TypeScript also gives you the option to tighten things up to bring you more type safety. You can\u00a0<\/span>learn more about TypeScript on our website<\/a>.<\/p>\n

To start using TypeScript, you can grab it\u00a0<\/span>through NuGet<\/a>\u00a0<\/span>or use the following command with npm:<\/p>\n

\n
npm install -g typescript<\/pre>\n<\/div>\n
Visual Studio 2015 users (who have\u00a0<\/span>Update 3<\/a>)\u00a0<\/span>can install TypeScript 2.5 from here<\/a>, and Visual Studio 2017 users using\u00a0<\/span>version 15.2 or later<\/a>\u00a0<\/span>will be able to get TypeScript\u00a0<\/span>by simply installing it from here<\/a>. Visual Studio 2017 users should be sure to read up on how you can configure your project to target specific versions of TypeScript<\/a>.<\/p>\n
While TypeScript 2.5 will be available for other editors soon, in the meantime you can configure\u00a0<\/span>Visual Studio Code<\/a>\u00a0<\/span>and\u00a0<\/span>Sublime Text<\/a>\u00a0<\/span>to use a newer version.\u00a0<\/span>Other editors<\/a>\u00a0<\/span>may have different approaches to getting TypeScript 2.5 running.<\/p>\n
Let’s look at what TypeScript 2.5 brings!<\/p>\n
<\/a>The\u00a0<\/span>Extract Function<\/em>\u00a0<\/span>and\u00a0<\/span>Extract Method<\/em>\u00a0<\/span>refactorings<\/h2>\n
Our team is always in search of ways to bring more powerful tools to the TypeScript and JavaScript world. That’s why with TypeScript 2.5 we’ve invested a lot into implementing\u00a0<\/span>extract method<\/em>\u00a0<\/span>and\u00a0<\/span>extract function<\/em>: two new refactorings that make complex rewrites trivial.<\/p>\n
If you’re using Visual Studio Code, this refactoring will be available in the upcoming release (though you can try it now by\u00a0<\/span>using VS Code Insiders releases<\/a>).<\/p>\n
This feature is still fairly new so we expect that there will still be room for improvement, but we’re excited to hear your feedback so we can polish things out.<\/p>\n
<\/a>New quick fixes<\/h2>\n
We’ve also added a few quick fixes for when TypeScript can guess a little bit at what you meant to write.<\/p>\n
One new quick fix will get triggered when you try to use JSDoc-style types in TypeScript. If you’re in the habit of writing types like these, you might be surprised to find out that they’re not valid in TypeScript, but TypeScript is happy to push us in the right direction.<\/p>\n
\"Quick<\/p>\n
We’ve also added a quick fix for when you try to reference the type of a property off of another type incorrectly. For example, for the following code<\/p>\n
\n
interface<\/span> Foo<\/span> {\n    bar:<\/span> number<\/span>;\n}<\/pre>\n<\/div>\n
We might want to declare a variable named\u00a0<\/span>xyz<\/code>\u00a0<\/span>whose type is tied to to the type of\u00a0<\/span>bar<\/code>. The correct way to write this would be using an indexed access type:<\/p>\n
\n
\/\/ Get the type of the property named 'bar' off of 'Foo'.<\/span>\nvar<\/span> xyz:<\/span> Foo<\/span>[\"<\/span>bar\"<\/span><\/span>]<\/pre>\n<\/div>\n
but we might accidentally write\u00a0<\/span>var xyz: Foo.bar<\/code>. TypeScript now can now suggest the correct one in many cases.<\/p>\n
\"A<\/p>\n
<\/a>JSDoc type assertion support in JavaScript files<\/h2>\n
In TypeScript 2.4, we introduced the ability to get type-checking in JavaScript files so that users can more easily migrate to TypeScript, and have an easier experience with certain more lightweight projects. Taking advantage of this is as simple as adding a\u00a0<\/span>\/\/ @ts-check<\/code>\u00a0<\/span>at the top of your\u00a0<\/span>.js<\/code>\u00a0<\/span>file, or turning on the\u00a0<\/span>checkJs<\/code>\u00a0<\/span>flag in yout\u00a0<\/span>tsconfig.json<\/code>‘s\u00a0<\/span>compilerOptions<\/code>.<\/p>\n
One thing that it lacked was the ability to “cast” or “assert” the type of an expression. This is important for situations where you know a little more than the type-checker and need to tell it so. To come up with a trivial example, let’s take the following JavaScript code:<\/p>\n
\n
\/\/ @ts-check<\/span>\n\nvar<\/span> foo =<\/span> Math<\/span>.random<\/span>() ?<\/span> \"<\/span>hello\"<\/span><\/span> :<\/span> 100<\/span>;\n\nfoo<\/span>.toUpperCase<\/span>();\n\/\/  ~~~~~~~~~~~<\/span>\n\/\/  Error! Property 'toUpperCase' does not exist on type 'string | number'.<\/span><\/pre>\n<\/div>\n
TypeScript correctly indicates that we might be calling a method that doesn’t exist on\u00a0<\/span>number<\/code>s. If we wanted to get around this so we can easily get our runtime error, we could write a JSDoc type assertion:<\/p>\n
\n
\/\/ Works!<\/span>\nvar<\/span> bar =<\/span> \/** @type<\/span> {string}<\/span> *\/<\/span> (foo);\nbar<\/span>.toUpperCase<\/span>();<\/pre>\n<\/div>\n
The syntax is\u00a0<\/span>\/** @type {YOUR_TYPE_HERE} *\/ (someParenthesizedExpression)<\/code>.<\/p>\n
Keep in mind that if you’ve enabled JavaScript checking on a file, invalid type assertions will still get caught:<\/p>\n
\n
var<\/span> clearlyNumber =<\/span> \/** @type<\/span> {string}<\/span> *\/<\/span> (100<\/span>);\n\/\/                      ~~~~~~~~~~~~~~<\/span>\n\/\/ Error! Type 'number' cannot be converted to type 'string'.<\/span><\/pre>\n<\/div>\n
<\/a>Optional\u00a0<\/span>catch<\/code>\u00a0<\/span>clauses<\/h2>\n
Thanks to work by\u00a0<\/span>Tingan Ho<\/a>, TypeScript 2.5 brings a new ECMAScript-bound feature for making catch clauses optional. Much of the time, you’ll find yourself writing a\u00a0<\/span>try<\/code>\/catch<\/code>\u00a0<\/span>but not really caring about the thrown error. For example:<\/p>\n
\n
let<\/span> contents;\ntry<\/span> {\n    contents<\/span> =<\/span> fs<\/span>.readFileSync<\/span>(\"<\/span>.config_file\"<\/span><\/span>).toString<\/span>('<\/span>utf8'<\/span><\/span>);\n}\ncatch<\/span> (unusedError<\/span>) {\n    \/\/ File might not exist, just fall back to some defaults.<\/span>\n    contents<\/span> =<\/span> createDefaultContents<\/span>();\n}<\/pre>\n<\/div>\n
Notice that\u00a0<\/span>unusedError<\/code>\u00a0<\/span>is never referenced in the above example. Barring philosophical issues about whether it’s appropriate to ignore the error, we can make our code a little cleaner by taking advantage of the fact that the\u00a0<\/span>catch<\/code>\u00a0<\/span>variable is now optional.<\/p>\n
\n
let<\/span> contents;\ntry<\/span> {\n    contents<\/span> =<\/span> fs<\/span>.readFileSync<\/span>(\"<\/span>.config_file\"<\/span><\/span>).toString<\/span>('<\/span>utf8'<\/span><\/span>);\n}\ncatch<\/span> {\n    \/\/ File might not exist, just fall back to some defaults.<\/span>\n    contents<\/span> =<\/span> createDefaultContents<\/span>();\n}<\/pre>\n<\/div>\n
<\/a>Deduplicated and redirected packages<\/h2>\n
When importing using the\u00a0<\/span>Node<\/code>\u00a0<\/span>module resolution strategy in TypeScript 2.5, the compiler will now check whether files originate from “identical” packages. If a file originates from a package with a\u00a0<\/span>package.json<\/code>\u00a0<\/span>containing the same\u00a0<\/span>name<\/code>\u00a0<\/span>and\u00a0<\/span>version<\/code>\u00a0<\/span>fields as a previously encountered package, then TypeScript will redirect itself to the top-most package. This helps resolve problems where two packages might contain identical declarations of classes, but which contain\u00a0<\/span>private<\/code>\u00a0<\/span>members that cause them to be structurally incompatible.<\/p>\n
As a nice bonus, this can also reduce the memory and runtime footprint of the compiler and language service by avoiding loading\u00a0<\/span>.d.ts<\/code>\u00a0<\/span>files from duplicate packages.<\/p>\n
<\/a>The\u00a0<\/span>--preserveSymlinks<\/code>\u00a0<\/span>compiler flag<\/h2>\n
TypeScript 2.5 brings the\u00a0<\/span>preserveSymlinks<\/code>\u00a0<\/span>flag, which parallels the behavior of\u00a0<\/span>the\u00a0<\/span>--preserve-symlinks<\/code>\u00a0<\/span>flag in Node.js<\/a>. This flag also exhibits the opposite behavior to Webpack’s\u00a0<\/span>resolve.symlinks<\/code>\u00a0<\/span>option (i.e. setting TypeScript’s\u00a0<\/span>preserveSymlinks<\/code>\u00a0<\/span>to\u00a0<\/span>true<\/code>\u00a0<\/span>parallels setting Webpack’s\u00a0<\/span>resolve.symlinks<\/code>\u00a0<\/span>to\u00a0<\/span>false<\/code>, and vice-versa).<\/p>\n
In this mode, references to modules and packages (e.g.\u00a0<\/span>import<\/code>s and\u00a0<\/span>\/\/\/ <reference type=\"...\" \/><\/code>\u00a0<\/span>directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to. For a more concrete example, we’ll defer to\u00a0<\/span>the documentation on the Node.js website<\/a>.<\/p>\n
<\/a>Enjoy!<\/h2>\n
We hope our work in TypeScript 2.5 will make you happier and more productive. If it did, let us know on Twitter with the\u00a0<\/span>#iHeartTypeScript<\/a>\u00a0<\/span>hashtag.<\/p>\n
Out team appreciates any sort of feedback on how we can improve. Feel free to let us know about any issues you run into or helpful ideas you think might make TypeScript even better to use\u00a0<\/span>on our GitHub issue tracker<\/a>.<\/p>\n
As for what’s next, we’ve caught most of what’s new on this blog post, but you can always check out our\u00a0<\/span>what’s new in TypeScript<\/a>\u00a0<\/span>page on our wiki for some more details, and keep an eye on\u00a0<\/span>our Roadmap<\/a>\u00a0<\/span>that highlights our current plans and is frequently updated.<\/p>\n
Thanks for reading and happy hacking!\n<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"
Today we’re happy to bring you TypeScript 2.5! If you’ve read\u00a0our RC announcement, we’ve got a few new items that we’re proud to highlight! If you’re not familiar with TypeScript, it’s a typed superset of JavaScript. More simply put, it’s just JavaScript with optional static types. Static types can make it easier to maintain your […]<\/p>\n","protected":false},"author":381,"featured_media":1797,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1145","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"
Today we’re happy to bring you TypeScript 2.5! If you’ve read\u00a0our RC announcement, we’ve got a few new items that we’re proud to highlight! If you’re not familiar with TypeScript, it’s a typed superset of JavaScript. More simply put, it’s just JavaScript with optional static types. Static types can make it easier to maintain your […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1145","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/users\/381"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/comments?post=1145"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1145\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media\/1797"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media?parent=1145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=1145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=1145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}