{"id":1215,"date":"2017-10-31T17:04:29","date_gmt":"2017-10-31T17:04:29","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1215"},"modified":"2019-02-20T10:45:43","modified_gmt":"2019-02-20T17:45:43","slug":"announcing-typescript-2-6","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-6\/","title":{"rendered":"Announcing TypeScript 2.6"},"content":{"rendered":"
\nTypeScript 2.6 is here in time for Halloween, but have no fear! We’ve got some great treats for you in this release.<\/p>\n

If you haven’t heard of TypeScript, it’s a language that builds on top of the most up-to-date versions of JavaScript by adding optional static types. These types don’t just help catch things like typos and logic errors; they also can bring you even better tooling like editor completions, easier navigation of your codebase, and more. Best of all, you don’t always have to write out your type annotations – TypeScript can often infer them for you!<\/p>\n

To learn more about TypeScript itself, you can visit our website<\/a>, but if you’re already familiar with it and want to try out the release, we have it available over NuGet<\/a> or through npm using the following command:<\/p>\n

\n
npm install -g typescript<\/pre>\n<\/div>\n
Visual Studio 2015 users (who have Update 3<\/a>) can install TypeScript 2.6 from here<\/a>, and Visual Studio 2017 users using version 15.2 or later<\/a> will be able to get TypeScript 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
TypeScript 2.6 will be available for other editors soon. In the meantime you can configure Visual Studio Code<\/a> and Sublime Text<\/a> to use a newer version. Other editors<\/a> may have different approaches to getting TypeScript 2.6 running.<\/p>\n
Let’s see what’s ready today in TypeScript 2.6!<\/p>\n
Contravariant parameter types with --strictFunctionTypes<\/code><\/h2>\n
When comparing signatures – things that make your types callable<\/em> or constructable<\/em> – TypeScript has to account for both the return types and the parameter types.<\/p>\n
Return types are easy – for a function f<\/code> to be assignable to g<\/code>, f<\/code>‘s return type has to be assignable to g<\/code>‘s return type. The fact that the directionality doesn’t change in this comparison is called covariance<\/em>.<\/p>\n
However, parameters are actually a different story – the correct approach is to go in the opposite direction! To see why, let’s take a quick example where we assign the below function g<\/code> to f<\/code>:<\/p>\n
\n
interface<\/span> Animal<\/span> { animalProp:<\/span> any<\/span> };\ninterface<\/span> Dog<\/span> extends<\/span> Animal<\/span> { dogProp:<\/span> any<\/span> };\n\nlet<\/span> f =<\/span> (animal<\/span>:<\/span> Animal<\/span>) =><\/span> animal<\/span>.animalProp<\/span>;\nlet<\/span> g =<\/span> (dog<\/span>:<\/span> Dog<\/span>) =><\/span> dog<\/span>.dogProp<\/span>;\n\n\/\/ Should this succeed?<\/span>\nf<\/span> =<\/span> g<\/span>;<\/pre>\n<\/div>\n
At a glance, we might be tempted to say that since Dog<\/code> is assignable to Animal<\/code>, g<\/code> is assignable to f<\/code>, but that’s not the case. It becomes clear once we ask the right questions about substitutability:<\/p>\n