{"id":1197,"date":"2017-10-12T19:01:18","date_gmt":"2017-10-12T19:01:18","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1197"},"modified":"2019-02-20T10:45:45","modified_gmt":"2019-02-20T17:45:45","slug":"announcing-typescript-2-6-rc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-6-rc\/","title":{"rendered":"Announcing TypeScript 2.6 RC"},"content":{"rendered":"
\n<\/div>\n

TypeScript 2.6 RC is now available! To get started with the latest stable version of TypeScript, you can grab it through NuGet<\/a>, or use the following command with npm:<\/p>\n

\n
npm install -g typescript@rc<\/pre>\n<\/div>\n
Visual Studio 2015 users (who have Update 3<\/a>)  can install TypeScript 2.6 RC from here<\/a>, and Visual Studio 2017 users using version 15.2 or later will be able to get TypeScript by simply installing it from here<\/a>.<\/p>\n
You can get TypeScript 2.6 RC working with Visual Studio Code<\/a> and Sublime Text<\/a>, though the full release of TypeScript 2.6 will be available out of the box.<\/p>\n
Let’s take a look at what TypeScript 2.6 will bring!<\/p>\n
 Contravariant function parameters with strictFunctionTypes<\/code><\/h2>\n
With TypeScript 2.6, we’re introducing a new --strict<\/code> mode flag: --strictFunctionTypes<\/code>. TypeScript has traditionally compared parameters in a bivariant manner. There are a number of reasons for this – modeling event handlers in the DOM, allowing a simpler model for working with arrays, and more.<\/p>\n
In TypeScript 2.4<\/a>, we tightened these checks a bit, but a few problems still remained. For example, the following would compile with no errors:<\/p>\n
\n
function<\/span> makeLowerCase(s<\/span>:<\/span> string<\/span>) {\n    return<\/span> s<\/span>.toLowerCase<\/span>();\n}\n\ndeclare<\/span> let<\/span> foo:<\/span> Promise<\/span><string<\/span> |<\/span> number<\/span>>;\nfoo<\/span>.then<\/span>(makeLowerCase<\/span>); \/\/ Whoops!<\/span><\/pre>\n<\/div>\n
While this is a very basic example, we re-evaluated our design decisions based on how JavaScript is written today and will be in the coming years, and felt that there were improvements we could make while accomodating the patterns described above.<\/p>\n
Under --strictFunctionTypes<\/code>, any function type that doesn’t originate from a method has its parameters compared contravariantly<\/em>. That means that the above code will fail, because when we try to pass makeLowerCase<\/code> with the type (s: string) => string<\/code> to then<\/code> which expects a function of type (onfulfilled: string | number) => ...<\/code>, we’ll flip directions and try to assess whether string | number<\/code> is assignable to string<\/code> which it isn’t.<\/p>\n
The compromise of increasing strictness on all function types but methods also allows TypeScript to continue modeling the above use-cases (e.g. event handlers and simpler array handling).<\/p>\n
Covariance and contravariance<\/a> probably deserve a a more thorough explanation. If you’d like to read a bit more, some of us on the team felt that this article<\/a> gives a reasonable high-level explanation. You can also read up more on the original pull request<\/a>. But the short version is that with --strictFunctionTypes<\/code>, you’ll be able to catch many common mistakes.<\/p>\n
Keep in mind that while --strictFunctionTypes<\/code> is opt-in, it will automatically be turned on if you’re operating with the --strict<\/code> flag on. This may introduce some breaks, so to disable the check with --strict<\/code> on, you can specify --strictFunctionTypes false<\/code> on the command line or in your tsconfig.json<\/code> as so:<\/p>\n
\n
{\n    \"<\/span>compilerOptions\"<\/span><\/span>: {\n        \"<\/span>strict\"<\/span><\/span>: true<\/span>,\n        \"<\/span>strictFunctionTypes\"<\/span><\/span>: false<\/span>\n    }\n}<\/pre>\n<\/div>\n
 Error suppression comments with \/\/ @ts-ignore<\/code><\/h2>\n
Historically, we’ve avoided error suppression within TypeScript because most cases where our users asked for it could be solved through more accurate declaration files, or using a type assertion to any<\/code>. However, over time, we have seen two motivating examples: migrating from JavaScript to TypeScript, and overcoming type-checks that live in legacy code.<\/p>\n
For the former, the benefits are obvious: you want to start moving over to TypeScript, but you’ve run into a pattern that is particularly difficult to model. You could spend time trying to understand it, but maybe you’d rather get rid of it later on anyway, so you just want to avoid errors because your code will still run just fine.<\/p>\n
The latter situation is a bit less obvious. The motivation here was that within some large organizations, dependencies across projects are updated in tandem, including TypeScript itself and @types<\/code> declaration files from Definitely Typed. If any change introduces a type-checking error, someone has to fix that to avoid breaking the build. But now a question arises: who should that be on an unmaintained project? While the error is usually useful, the reality of the situation is that the code has functioned thus far and teams have finite resources.<\/p>\n
That’s why with TypeScript 2.6 we’re bringing \/\/ @ts-ignore<\/code> comments to TypeScript files. These comments suppress any errors that occur on the next line. For example, in the following code, TypeScript would ordinarily report an error about the console.log<\/code> statement being unreachable. In TypeScript 2.6, the \/\/ @ts-ignore<\/code> comment squelches the error entirely.<\/p>\n
\n
if<\/span> (false<\/span>) {\n    \/\/ @ts-ignore: Unreachable code error<\/span>\n    console<\/span>.log<\/span>(\"<\/span>hello\"<\/span><\/span>);\n}<\/pre>\n<\/div>\n
While this feature is motivated by pragmatism, we encourage taking type-checking errors seriously. Our guidance here is to use suppression comments very sparingly<\/em>. In situations where you do<\/em> need to use these comments, we suggest leaving a trailing explanation of why the comment is necessary like in the example above.<\/p>\n
 Revised tagged template emit<\/h2>\n
Tagged template strings have been supported and type-checked in TypeScript for quite some time now. Let’s take a simple example of a tagged template string:<\/p>\n
\n
function<\/span> foo(arg<\/span>:<\/span> TemplateStringsArray<\/span>) {\n    return<\/span> arg<\/span>;\n}\n\nfunction<\/span> bar() {\n    return<\/span> foo<\/span> `<\/span>hello world`<\/span><\/span>;\n}<\/pre>\n<\/div>\n
When emitting to ES3\/ES5, that tagged template more or less boils down to calling foo<\/code> like so:<\/p>\n
\n
function<\/span> foo(arg) {\n    return<\/span> arg<\/span>;\n}\nfunction<\/span> bar() {\n    var<\/span> _a =<\/span> [\"<\/span>hello world\"<\/span><\/span>];\n    _a<\/span>.raw<\/span> =<\/span> [\"<\/span>hello world\"<\/span><\/span>];\n    foo<\/span>(_a<\/span>);\n}<\/pre>\n<\/div>\n
However, the ECMAScript specification says that every time foo `hello world`<\/code> gets invoked, foo<\/code> will get the same template object, so re-initializing _a<\/code> in bar<\/code> is incorrect. This is problematic because some libraries have an expectation that with the above example, any invocation of bar()<\/code> will return the same value.<\/p>\n
In TypeScript 2.6, within a module, tagged template string objects are now cached after the first invocation. This aligns more closely with recent revisions to the ECMAScript spec, and we will be following up with this behavior to ensure it correctly works within global code as well.<\/p>\n
This also means that TypeScript users can use libraries like lit-html<\/a> and hyperHTML<\/a> which take advantage of the new behavior.<\/p>\n
 Breaking changes and deprecations<\/h2>\n
There are several minor changes that may impact your codebase. While you can read up more about them in our Breaking Changes<\/a> section, please keep these in mind when upgrading.<\/p>\n