{"id":1245,"date":"2018-01-17T18:14:41","date_gmt":"2018-01-17T18:14:41","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1245"},"modified":"2021-08-10T09:48:16","modified_gmt":"2021-08-10T17:48:16","slug":"announcing-typescript-2-7-rc","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-2-7-rc\/","title":{"rendered":"Announcing TypeScript 2.7 RC"},"content":{"rendered":"
\n
Today we’re publishing the Release Candidate of TypeScript 2.7. To get started with the RC, you can access it through NuGet<\/a>, or use npm with the following command:<\/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.7 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 also get the Release Candidate working with Visual Studio Code<\/a> and Sublime Text<\/a>.<\/p>\n
While we have many new features and fixes, we have a few highlights for the RC we think are especially important.<\/p>\n
Definite Assignment Checks for Class Properties<\/h2>\n
TypeScript 2.7 introduces a new flag called --strictPropertyInitialization<\/code>. This flag performs checks to ensure that each instance property of a class gets initialized in the constructor body, or by a property initializer. For example<\/p>\n
\n
class<\/span> C<\/span> {\r\n    foo:<\/span> number<\/span>;\r\n    bar =<\/span> \"<\/span>hello\"<\/span><\/span>;\r\n    baz:<\/span> boolean<\/span>;\r\n\/\/  ~~~<\/span>\r\n\/\/  Error! Property 'baz' has no initializer and is not definitely assigned in the constructor.<\/span>\r\n    constructor<\/span>() {\r\n        this<\/span>.foo<\/span> =<\/span> 42<\/span>;\r\n    }\r\n}<\/pre>\n<\/div>\n
In the above, if we truly meant for baz<\/code> to potentially be undefined<\/code>, we should have declared it with the type boolean | undefined<\/code>.<\/p>\n
There are certain scenarios where properties can be initialized indirectly (perhaps by a helper method or dependency injection library), in which case you can use the new definite assignment assertion modifiers<\/em> for your properties.<\/p>\n
\n
class<\/span> C<\/span> {\r\n    foo<\/span>!<\/span>:<\/span> number<\/span>;\r\n    \/\/ ^<\/span>\r\n    \/\/ Notice this '!' modifier.<\/span>\r\n    \/\/ This is the \"definite assignment assertion\"<\/span>\r\n\r\n    constructor<\/span>() {\r\n        this<\/span>.initialize<\/span>();\r\n    }\r\n\r\n    initialize() {\r\n        this<\/span>.foo<\/span> =<\/span> 0<\/span>;\r\n    }\r\n}<\/pre>\n<\/div>\n
Keep in mind that --strictPropertyInitialization<\/code> will be turned on along with other --strict<\/code> mode flags, which can impact your project. You can set the strictPropertyInitialization<\/code> setting to false<\/code> in your tsconfig.json<\/code>‘s compilerOptions<\/code>, or --strictPropertyInitialization false<\/code> on the command line to turn off this checking.<\/p>\n
Fixed Length Tuples<\/h2>\n
In TypeScript 2.6 and earlier, [number, string, string]<\/code> was considered a subtype of [number, string]<\/code>. This was motivated by TypeScript’s structural nature; the first and second elements of a [number, string, string]<\/code> are respectively subtypes of the first and second elements of [number, string]<\/code>. However, after examining real world usage of tuples, we noticed that most situations in which this was permitted was typically undesirable.<\/p>\n
Thanks to a pull request from Kiara Grouwstra<\/a>, tuple types now encode their arity into the type of their respective length<\/code> property, and tuples of different arities are no longer assignable to each other. This is accomplished by leveraging numeric literal types, which now allow tuples to be distinct from tuples of different arities.<\/p>\n
Conceptually, you might consider the type [number, string]<\/code> to be equivalent to the following declaration of NumStrTuple<\/code>:<\/p>\n
\n
interface<\/span> NumStrTuple<\/span> extends<\/span> Array<\/span><number<\/span> |<\/span> string<\/span>> {\r\n    0<\/span>:<\/span> number<\/span>;\r\n    1<\/span>:<\/span> string<\/span>;\r\n    length:<\/span> 2<\/span>; \/\/ using the numeric literal type '2'<\/span>\r\n}<\/pre>\n<\/div>\n
Note that this is a breaking change. If you need to resort to the original behavior in which tuples only enforce a minimum size, you can use a similar declaration that does not explicitly define a length<\/code> property, falling back to number<\/code>.<\/p>\n
\n
interface<\/span> MinimumNumStrTuple<\/span> extends<\/span> Array<\/span><number<\/span> |<\/span> string<\/span>> {\r\n    0<\/span>:<\/span> number<\/span>;\r\n    1<\/span>:<\/span> string<\/span>;\r\n}<\/pre>\n<\/div>\n
Improved narrowing for in<\/code> and instanceof<\/code><\/h2>\n
Thanks to GitHub user IdeaHunter<\/a>, the in<\/code> operator now acts as a narrowing expression for types, narrowing out types that don’t explicitly declare properties of a given name.<\/p>\n
\n
interface<\/span> A<\/span> { a:<\/span> number<\/span> };\r\ninterface<\/span> B<\/span> { b:<\/span> string<\/span> };\r\n\r\nfunction<\/span> foo(x<\/span>:<\/span> A<\/span> |<\/span> B<\/span>) {\r\n    if<\/span> (\"<\/span>a\"<\/span><\/span> in<\/span> x<\/span>) {\r\n        return<\/span> x<\/span>.a<\/span>;\r\n    }\r\n    return<\/span> x<\/span>.b<\/span>;\r\n}<\/pre>\n<\/div>\n
Furthermore, the instanceof<\/code> operator is now leverages the inheritance chain instead of relying on structural compatibility, more accurately reflecting whether how instanceof<\/code> may behave at runtime.<\/p>\n
\n
\/\/ Error! <\/span>\r\nexport<\/span> class<\/span> C<\/span> {\r\n    foo =<\/span> 1<\/span>;\r\n}\r\n\r\nexport<\/span> class<\/span> D<\/span> extends<\/span> C<\/span> {\r\n    bar =<\/span> 2<\/span>;\r\n}\r\n\r\nexport<\/span> class<\/span> E<\/span> {\r\n    foo =<\/span> 3<\/span>;\r\n}\r\n\r\ndeclare<\/span> let<\/span> x:<\/span> C<\/span> |<\/span> D<\/span> |<\/span> E<\/span>;\r\n\r\nif<\/span> (x<\/span> instanceof<\/span> E<\/span>) {\r\n    x<\/span> \/\/ 'E', but previously 'D | E'<\/span>\r\n}\r\nelse<\/span> {\r\n    x<\/span> \/\/ 'C | D', but previously 'C'<\/span>\r\n}<\/pre>\n<\/div>\n
While we’ve witnessed positive changes in most codebases, be aware that any change in inference and narrowing can impact your compilation. Changes to type declarations, as well as type assertions, may be necessary.<\/p>\n
Breaking Changes<\/h2>\n
This release brings some minor breaking changes:<\/p>\n