{"id":1595,"date":"2018-07-30T16:40:37","date_gmt":"2018-07-30T16:40:37","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1595"},"modified":"2019-02-27T23:10:02","modified_gmt":"2019-02-28T07:10:02","slug":"announcing-typescript-3-0","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-3-0\/","title":{"rendered":"Announcing TypeScript 3.0"},"content":{"rendered":"<div style=\"font-size: 16px;\">\n<p>TypeScript 3.0 is here! Today marks a new milestone in the TypeScript journey, serving JavaScript users everywhere.If you&#8217;re unfamiliar with TypeScript, it&#8217;s not too late to learn about it now! TypeScript is an extension of JavaScript that aims to bring static types to modern JavaScript. The TypeScript compiler reads in TypeScript code, which has things like type declarations and type annotations, and emits clean readable JavaScript with those constructs transformed and removed. That code runs in any ECMAScript runtime like your favorite browsers and Node.js. At its core, this experience means analyzing your code to catch things like bugs and typos before your users run into them; but it brings more than that. Thanks to all that information and analysis TypeScript can provide a better authoring experience, providing code completion and navigation features like <em>Find all References<\/em>, <em>Go to Definition<\/em>, and <em>Rename<\/em> in your favorite editor.<\/p>\n<p>To get started with the language itself, check out <a href=\"https:\/\/www.typescriptlang.org\/\" rel=\"nofollow\">typescriptlang.org<\/a> to learn more. And if you want to try TypeScript 3.0 out now, you can get it <a href=\"https:\/\/www.nuget.org\/packages\/Microsoft.TypeScript.MSBuild\" rel=\"nofollow\">through NuGet<\/a> or via npm by running<\/p>\n<div class=\"highlight highlight-source-shell\">\n<pre class=\"lang:default decode:true\">npm install -g typescript<\/pre>\n<\/div>\n<p>You can also get editor support for<\/p>\n<ul>\n<li><a href=\"http:\/\/download.microsoft.com\/download\/7\/0\/A\/70A6AC0E-8934-4396-A43E-445059F430EA\/3.0.1-TS-release-dev14update3-20180725.1\/TypeScript_SDK.exe\" rel=\"nofollow\">Visual Studio 2017<\/a> (for version 15.2 or later).<\/li>\n<li><a href=\"http:\/\/download.microsoft.com\/download\/6\/D\/8\/6D8381B0-03C1-4BD2-AE65-30FF0A4C62DA\/3.0.1-TS-release-dev14update3-20180725.1\/TypeScript_Dev14Full.exe\" rel=\"nofollow\">Visual Studio 2015<\/a> (which requires update 3).<\/li>\n<li>For Visual Studio Code <a href=\"https:\/\/code.visualstudio.com\/insiders\/\" rel=\"nofollow\">by installing the Insiders release<\/a> until the full release provides it.<\/li>\n<li><a href=\"https:\/\/packagecontrol.io\/packages\/TypeScript\" rel=\"nofollow\">Sublime Text 3 via PackageControl<\/a>.<\/li>\n<\/ul>\n<p><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/TypeScript-Editor-Support\">Other editors<\/a> may have different update schedules, but should all have excellent TypeScript support soon as well.<\/p>\n<h1 id=\"the-30-journey\">The 3.0 Journey<\/h2>\n<p>When we released TypeScript 2.0, we took a brief look back at how each release leading up to TypeScript 2.0 brought the language to where it is today. Between TypeScript 1.0 and up until 2.0, the language added union types, type guards, modern ECMAScript support, type aliases, JSX support, literal types, and polymorphic <code style=\"color: #a31515;\">this<\/code> types. If we include TypeScript 2.0 with its introduction of non-nullable types, control flow analysis, tagged union support, <code style=\"color: #a31515;\">this<\/code>-types, and a simplified model around <code style=\"color: #a31515;\">.d.ts<\/code> file acquisition, that era truly defined the fundamentals of using TypeScript.<\/p>\n<p>So what have we done since? What, apart from new ECMAScript features like the long-<em>await<\/em>-ed <code style=\"color: #a31515;\">async<\/code>\/<code style=\"color: #a31515;\">await<\/code>, generators, and object rest\/spread brought us to TypeScript 3.0?<\/p>\n<p>TypeScript 2.1 was a foundational release that introduced a static model for metaprogramming in JavaScript. The key query (<code style=\"color: #a31515;\">keyof<\/code>), indexed access (<code style=\"color: #a31515;\">T[K]<\/code>), and mapped object (<code style=\"color: #a31515;\">{ [K in keyof T]: T[K] }<\/code>) types have been instrumental in better modeling libraries like React, Ember, Lodash, and more.<\/p>\n<p>TypeScript 2.2 and 2.3 brought support for mixin patterns, the non-primitive <code style=\"color: #a31515;\">object<\/code> type, and generic defaults, used by a number of projects like Angular Material and Polymer. TypeScript 2.3 also shipped a feature for fine-grained control of <code style=\"color: #a31515;\">this<\/code> types that allowed TypeScript to work well with libraries like Vue, and added the <code style=\"color: #a31515;\">checkJs<\/code> flag to enable type-checking on JavaScript files.<\/p>\n<p>TypeScript 2.4 and 2.6 tightened up the story for strict checking on function types, addressing some of the longest-standing feedback about our type system through <code style=\"color: #a31515;\">--strictFunctionTypes<\/code> which enforced contravariance on parameters. 2.7 continued the trend of strictness with <code style=\"color: #a31515;\">--strictPropertyInitialization<\/code> checks in classes.<\/p>\n<p>TypeScript 2.8 introduced conditional types, a powerful tool for statically expressing decisions based on types, and 2.9 generalized <code style=\"color: #a31515;\">keyof<\/code> and provided easier imports for types.<\/p>\n<p>Which brings us to TypeScript 3.0! Despite the new big number, 3.0 has few breaking changes (meaning it should be <em>very<\/em> easy to upgrade) and introduces a new flexible and scalable way to structure your projects, powerful new support for operating on parameter lists, new types to enforce explicit checks, better JSX support, an overall better error UX, and much more!<\/p>\n<h1 id=\"whats-new\">What&#8217;s New?<\/h2>\n<ul>\n<li><a href=\"#project-references\">Project references<\/a>\n<ul>\n<li><a href=\"#build-mode\"><code style=\"color: #a31515;\">--build<\/code> mode<\/a><\/li>\n<li><a href=\"#controlling-output-structure\">Controlling output structure<\/a><\/li>\n<li><a href=\"#further-work\">Further work<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#tuples-and-parameters\">Extracting and spreading parameter lists with tuples<\/a><\/li>\n<li><a href=\"#richer-tuple-types\">Richer tuple types<\/a><\/li>\n<li><a href=\"#the-unknown-type\">The <code style=\"color: #a31515;\">unknown<\/code> type<\/a><\/li>\n<li><a href=\"#improved-errors-and-ux\">Improved errors and UX<\/a>\n<ul>\n<li><a href=\"#related-error-spans\">Related error spans<\/a><\/li>\n<li><a href=\"#Improved-messages-and-elaboration\">Improved messages and elaboration<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#default-props-support\">Support for <code style=\"color: #a31515;\">defaultProps<\/code> in JSX<\/a><\/li>\n<li><a href=\"#lib-directives\"><code style=\"color: #a31515;\">\/\/\/ &lt;reference lib=\"...\" \/&gt;<\/code> directives<\/a><\/li>\n<li><a href=\"#editor-productivity\">Editor Productivity<\/a>\n<ul>\n<li><a href=\"#named-import-refactorings\">Named import refactorings<\/a><\/li>\n<li><a href=\"#jsx-productivity\">Closing JSX tag completions and outlining spans<\/a><\/li>\n<li><a href=\"#remove-bogus-code\">Quick fixes for unreachable code and unused labels<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#breaking-changes\">Breaking changes<\/a>\n<ul>\n<li><a href=\"#unknown-is-a-reserved-type-name\"><code style=\"color: #a31515;\">unknown<\/code> is a reserved type name<\/a><\/li>\n<li><a href=\"#intersecting-with-nullundefined\">Intersecting with <code style=\"color: #a31515;\">null<\/code>\/<code style=\"color: #a31515;\">undefined<\/code> reduces to <code style=\"color: #a31515;\">null<\/code>\/<code style=\"color: #a31515;\">undefined<\/code> outside of <code style=\"color: #a31515;\">strictNullChecks<\/code><\/a><\/li>\n<li><a href=\"#api-breaking-changes\">API breaking changes<\/a><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2 id=\"project-references\">Project references<\/h2>\n<p>It&#8217;s fairly common to have several different build steps for a library or application. Maybe your codebase has a <code style=\"color: #a31515;\">src<\/code> and a <code style=\"color: #a31515;\">test<\/code> directory. Maybe you have your front-end code in a folder called <code style=\"color: #a31515;\">client<\/code> with your Node.js back-end code in a folder called <code style=\"color: #a31515;\">server<\/code>, and each imports code from a <code style=\"color: #a31515;\">shared<\/code> folder. And maybe you use what&#8217;s called a &#8220;monorepo&#8221; and have many many projects which depend on each other in non-trivial ways.<\/p>\n<p>One of the biggest features that we&#8217;ve worked on for TypeScript 3.0 is called &#8220;project references&#8221;, and it aims to make working with these scenarios easier.<\/p>\n<p>Project references allow TypeScript projects to depend on other TypeScript projects &#8211; specifically, allowing <code style=\"color: #a31515;\">tsconfig.json<\/code> files to reference other <code style=\"color: #a31515;\">tsconfig.json<\/code> files. Specifying these dependencies makes it easier to split your code into smaller projects, since it gives TypeScript (and tools around it) a way to understand build ordering and output structure. That means things like faster builds that work incrementally, and support for transparently navigating, editing, and refactoring across projects. Since 3.0 lays the foundation and exposes the APIs, any build tool should be able to provide this.<\/p>\n<h3 id=\"whats-it-look-like\">What&#8217;s it look like?<\/h3>\n<p>As a quick example, here&#8217;s what a <code style=\"color: #a31515;\">tsconfig.json<\/code> with project references looks like:<\/p>\n<pre class=\"lang:default decode:true\">\/\/ .\/src\/bar\/tsconfig.json\r\n{\r\n    \"compilerOptions\": {\r\n        \/\/ Needed for project references.\r\n        \"composite\": true,\r\n        \"declaration\": true,\r\n\r\n        \/\/ Other options...\r\n        \"outDir\": \"..\/..\/lib\/bar\",\r\n        \"strict\": true, \"module\": \"esnext\", \"moduleResolution\": \"node\",\r\n    },\r\n    \"references\": [\r\n        { \"path\": \"..\/foo\" }\r\n    ]\r\n}\r\n<\/pre>\n<p>There are two new fields to notice here: <code style=\"color: #a31515;\">composite<\/code> and <code style=\"color: #a31515;\">references<\/code>.<\/p>\n<p><code style=\"color: #a31515;\">references<\/code> simply specifies other <code style=\"color: #a31515;\">tsconfig.json<\/code> files (or folders immediately containing them). Each reference is currently just an object with a <code style=\"color: #a31515;\">path<\/code> field, and lets TypeScript know that building the current project requires building that referenced project first.<\/p>\n<p>Perhaps equally important is the <code style=\"color: #a31515;\">composite<\/code> field. The <code style=\"color: #a31515;\">composite<\/code> field ensures certain options are enabled so that this project can be referenced and built incrementally for any project that depends on it. Being able to intelligently and incrementally rebuild is important, since build speed is one of the reasons you might break up a project in the first place. For example, if project <code style=\"color: #a31515;\">front-end<\/code> depends on <code style=\"color: #a31515;\">shared<\/code>, and <code style=\"color: #a31515;\">shared<\/code> depends on <code style=\"color: #a31515;\">core<\/code>, our APIs around project references can be used to detect a change in <code style=\"color: #a31515;\">core<\/code>, but to only rebuild <code style=\"color: #a31515;\">shared<\/code> if the types (i.e. the <code style=\"color: #a31515;\">.d.ts<\/code> files) produced by <code style=\"color: #a31515;\">core<\/code> have changed. That means a change to <code style=\"color: #a31515;\">core<\/code> doesn&#8217;t completely force us to rebuild the world. For that reason, setting <code style=\"color: #a31515;\">composite<\/code> forces the <code style=\"color: #a31515;\">declaration<\/code> flag to be set as well.<\/p>\n<h3 id=\"build-mode\"><code style=\"color: #a31515; font-size: 26px;\">--build<\/code> mode<\/h3>\n<p>TypeScript 3.0 will provide a set of APIs for project references so that other tools can provide this fast incremental behavior. As an example, gulp-typescript already leverages it! So project references should be able to integrate with your choice of build orchestrators in the future.<\/p>\n<p>However, for many simple apps and libraries, it&#8217;s nice not to need external tools. That&#8217;s why <code style=\"color: #a31515;\">tsc<\/code> now ships with a new <code style=\"color: #a31515;\">--build<\/code> flag.<\/p>\n<p><code style=\"color: #a31515;\">tsc --build<\/code> (or its nickname, <code style=\"color: #a31515;\">tsc -b<\/code>) takes a set of projects and builds them and their dependencies. When using this new build mode, the <code style=\"color: #a31515;\">--build<\/code> flag has to be set first, and can be paired with certain other flags:<\/p>\n<ul>\n<li><code style=\"color: #a31515;\">--verbose<\/code>: displays every step of what a build requires<\/li>\n<li><code style=\"color: #a31515;\">--dry<\/code>: performs a build without emitting files (this is useful with <code style=\"color: #a31515;\">--verbose<\/code>)<\/li>\n<li><code style=\"color: #a31515;\">--clean<\/code>: attempts to remove output files given the inputs<\/li>\n<li><code style=\"color: #a31515;\">--force<\/code>: forces a full non-incremental rebuild for a project<\/li>\n<\/ul>\n<h3 id=\"controlling-output-structure\">Controlling output structure<\/h3>\n<p>One subtle but incredibly useful benefit of project references is logically being able to map your input source to its outputs.<\/p>\n<p>If you&#8217;ve ever tried to share TypeScript code between the client and server of your application, you might have run into problems controlling the output structure.<\/p>\n<p>For example, if <code style=\"color: #a31515;\">client\/index.ts<\/code> and <code style=\"color: #a31515;\">server\/index.ts<\/code> both reference <code style=\"color: #a31515;\">shared\/index.ts<\/code> for the following projects:<\/p>\n<pre><code>src\r\n\u251c\u2500\u2500 client\r\n\u2502   \u251c\u2500\u2500 index.ts\r\n\u2502   \u2514\u2500\u2500 tsconfig.json\r\n\u251c\u2500\u2500 server\r\n\u2502   \u251c\u2500\u2500 index.ts\r\n\u2502   \u2514\u2500\u2500 tsconfig.json\r\n\u2514\u2500\u2500 shared\r\n    \u2514\u2500\u2500 index.ts\r\n<\/code><\/pre>\n<p>&#8230;then trying to build <code style=\"color: #a31515;\">client<\/code> and <code style=\"color: #a31515;\">server<\/code>, we&#8217;ll end up with&#8230;<\/p>\n<pre><code>lib\r\n\u251c\u2500\u2500 client\r\n\u2502   \u251c\u2500\u2500 client\r\n\u2502   \u2502   \u2514\u2500\u2500 index.js\r\n\u2502   \u2514\u2500\u2500 shared\r\n\u2502       \u2514\u2500\u2500 index.js\r\n\u2514\u2500\u2500 server\r\n    \u251c\u2500\u2500 server\r\n    \u2502   \u2514\u2500\u2500 index.js\r\n    \u2514\u2500\u2500 shared\r\n        \u2514\u2500\u2500 index.js\r\n<\/code><\/pre>\n<p>rather than<\/p>\n<pre><code>lib\r\n\u251c\u2500\u2500 client\r\n\u2502   \u2514\u2500\u2500 index.js\r\n\u251c\u2500\u2500 shared\r\n\u2502   \u2514\u2500\u2500 index.js\r\n\u2514\u2500\u2500 server\r\n    \u2514\u2500\u2500 index.js\r\n<\/code><\/pre>\n<p>Notice that we ended up with a copy of <code style=\"color: #a31515;\">shared<\/code> in both <code style=\"color: #a31515;\">client<\/code> and <code style=\"color: #a31515;\">server<\/code>. We unnecessarily spent time building <code style=\"color: #a31515;\">shared<\/code> twice and introduced an undesirable level of nesting in <code style=\"color: #a31515;\">lib\/client\/client<\/code> and <code style=\"color: #a31515;\">lib\/server\/server<\/code>.<\/p>\n<p>The problem is that TypeScript greedily looks for <code style=\"color: #a31515;\">.ts<\/code> files and tries to include them in a given compilation. Ideally, TypeScript would understand that these files don&#8217;t need to be built in the same compilation, and would instead jump to the <code style=\"color: #a31515;\">.d.ts<\/code> files for type information.<\/p>\n<p>Creating a <code style=\"color: #a31515;\">tsconfig.json<\/code> for <code style=\"color: #a31515;\">shared<\/code> and using project references does exactly that. It signals to TypeScript that<\/p>\n<ol>\n<li><code style=\"color: #a31515;\">shared<\/code> should be built independently, and that<\/li>\n<li>when importing from <code style=\"color: #a31515;\">..\/shared<\/code>, we should look for the <code style=\"color: #a31515;\">.d.ts<\/code> files in its output directory.<\/li>\n<\/ol>\n<p>This avoids triggering a double-build, and also avoids accidentally absorbing all the contents of <code style=\"color: #a31515;\">shared<\/code>.<\/p>\n<h3 id=\"further-work\">Further work<\/h3>\n<p>To get a deeper understanding of project references and how you can use them, <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/3469#issuecomment-400439520\">read up more our issue tracker<\/a>. In the near future, we&#8217;ll have documentation on project references and build mode.<\/p>\n<p>We&#8217;re committed to ensuring that other tool authors can support project references, and will continue to improve the editing experience around project references. Our intent is for project references to feel as seamless as authoring code with a single <code style=\"color: #a31515;\">tsconfig.json<\/code>. If you do end up using project references, we&#8217;d appreciate any and all feedback to do just that.<\/p>\n<h2 id=\"tuples-and-parameters\">Extracting and spreading parameter lists with tuples<\/h2>\n<p>We often take it for granted, but JavaScript lets us think about parameter lists as first-class values &#8211; either by using <code style=\"color: #a31515;\">arguments<\/code> or rest-parameters (e.g. <code style=\"color: #a31515;\">...rest<\/code>).<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">function call(fn, ...args) {\r\n    return fn(...args);\r\n}<\/pre>\n<\/div>\n<p>Notice here that <code style=\"color: #a31515;\">call<\/code> works on functions of any parameter length. Unlike other languages, JavaScript doesn&#8217;t force us to define a <code style=\"color: #a31515;\">call0<\/code>, <code style=\"color: #a31515;\">call1<\/code>, <code style=\"color: #a31515;\">call2<\/code>, etc. as follows:<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">function call0(fn) {\r\n    return fn();\r\n}\r\n\r\nfunction call1(fn, param1) {\r\n    return fn(param1);\r\n}\r\n\r\nfunction call2(fn, param1, param2) {\r\n    return fn(param1, param2);\r\n}\r\n\r\nfunction call3(fn, param1, param2, param3) {\r\n    return fn(param1, param2, param3);\r\n}<\/pre>\n<\/div>\n<p>Unfortunately, for a while there wasn&#8217;t a great well-typed way to express this statically in TypeScript without declaring a finite number of overloads:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/\/ TODO (billg): 5 overloads should *probably* be enough for anybody?\r\nfunction call&lt;T1, T2, T3, T4, R&gt;(fn: (param1: T1, param2: T2, param3: T3, param4: T4) =&gt; R, param1: T1, param2: T2, param3: T3, param4: T4): R\r\nfunction call&lt;T1, T2, T3, R&gt;(fn: (param1: T1, param2: T2, param3: T3) =&gt; R, param1: T1, param2: T2, param3: T3): R\r\nfunction call&lt;T1, T2, R&gt;(fn: (param1: T1, param2: T2) =&gt; R, param1: T1, param2: T2): R\r\nfunction call&lt;T1, R&gt;(fn: (param1: T1) =&gt; R, param1: T1): R;\r\nfunction call&lt;R&gt;(fn: () =&gt; R, param1: T1): R;\r\nfunction call(fn: (...args: any[]) =&gt; any, ...args: any[]) {\r\n    return fn(...args);\r\n}<\/pre>\n<\/div>\n<p>Oof! Another case of death by a thousand overloads! Or at least, as many overloads as our users asked us for.<\/p>\n<p>TypeScript 3.0 allows us to better model scenarios like these by now allowing rest parameters to be generic, and inferring those generics as tuple types! Instead of declaring each of these overloads, we can say that the <code style=\"color: #a31515;\">...args<\/code> rest parameter from <code style=\"color: #a31515;\">fn<\/code> must be a type parameter that extends an array, and then we can re-use that for the <code style=\"color: #a31515;\">...args<\/code> that <code style=\"color: #a31515;\">call<\/code> passes:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function call&lt;TS extends any[], R&gt;(fn: (...args: TS) =&gt; R, ...args: TS): R {\r\n    return fn(...args);\r\n}<\/pre>\n<\/div>\n<p>When we call the <code style=\"color: #a31515;\">call<\/code> function, TypeScript will try to extract the parameter list from whatever we pass to <code style=\"color: #a31515;\">fn<\/code>, and turn that into a tuple:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function foo(x: number, y: string): string {\r\n    return (x + y).toLowerCase();\r\n}\r\n\r\n\/\/ The `TS` type parameter is inferred as `[number, string]`\r\ncall(foo, 100, \"hello\");<\/pre>\n<\/div>\n<p>When TypeScript infers <code style=\"color: #a31515;\">TS<\/code> as <code style=\"color: #a31515;\">[number, string]<\/code> and we end up re-using <code style=\"color: #a31515;\">TS<\/code> on the rest parameter of <code style=\"color: #a31515;\">call<\/code>, the instantiation looks like the following<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function call(fn: (...args: [number, string]) =&gt; string, ...args: [number, string]): string<\/pre>\n<\/div>\n<p>And with TypeScript 3.0, using a tuple in a rest parameter gets <em>flattened<\/em> into the rest of the parameter list! The above boils down to simple parameters with no tuples:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function call(fn: (arg1: number, arg2: string) =&gt; string, arg1: number, arg2: string): string<\/pre>\n<\/div>\n<p>So in addition to catching type errors when we pass in the wrong arguments:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function call&lt;TS extends any[], R&gt;(fn: (...args: TS) =&gt; R, ...args: TS): R {\r\n    return fn(...args);\r\n}\r\n\r\ncall((x: number, y: string) =&gt; y, \"hello\", \"world\");\r\n\/\/                                ~~~~~~~\r\n\/\/ Error! `string` isn't assignable to `number`!<\/pre>\n<\/div>\n<p>and inference from other arguments:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">call((x, y) =&gt; { \/* .... *\/ }, \"hello\", 100);\r\n\/\/    ^  ^\r\n\/\/ `x` and `y` have their types inferred as `string` and `number` respectively.<\/pre>\n<\/div>\n<p>we can also observe the tuple types that these functions infer from the outside:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function tuple&lt;TS extends any[]&gt;(...xs: TS): TS {\r\n    return xs;\r\n}\r\n\r\nlet x = tuple(1, 2, \"hello\"); \/\/ has type `[number, number, string]`<\/pre>\n<\/div>\n<p>There is a subtler point to note though. In order to make all of this work, we needed to expand what tuples could do&#8230;<\/p>\n<h2 id=\"richer-tuple-types\">Richer tuple types<\/h2>\n<p>To make tuples model parameter lists (as we just discussed), we had to rethink tuple types a bit. Before TypeScript 3.0, the best that tuples could model was the order and count of a set of parameters.<\/p>\n<p>However, parameter lists aren&#8217;t just ordered lists of types. For example, parameters at the end can be optional:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/\/ Both `y` and `z` are optional here.\r\nfunction foo(x: boolean, y = 100, z?: string) {\r\n    \/\/ ...\r\n}\r\n\r\nfoo(true);\r\nfoo(true, undefined, \"hello\");\r\nfoo(true, 200);<\/pre>\n<\/div>\n<p>The last parameter can be a <em>rest<\/em> parameter.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/\/ `rest` accepts any number of strings - even none!\r\nfunction foo(...rest: string[]) {\r\n    \/\/ ...\r\n}\r\n\r\nfoo();\r\nfoo(\"hello\");\r\nfoo(\"hello\", \"world\");<\/pre>\n<\/div>\n<p>And finally, there is one mildly interesting property about parameter lists which is that they can be empty:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/\/ Accepts no parameters.\r\nfunction foo() {\r\n    \/\/ ...\r\n}\r\n\r\nfoo();<\/pre>\n<\/div>\n<p>So to make it possible for tuples to correspond to parameter lists, we needed to model each of these scenarios.<\/p>\n<p>First, tuples now allow trailing optional elements:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/**\r\n * 2D, or potentially 3D, coordinate.\r\n *\/\r\ntype Coordinate = [number, number, number?];<\/pre>\n<\/div>\n<p>The <code style=\"color: #a31515;\">Coordinate<\/code> type creates a tuple with an optional property named <code style=\"color: #a31515;\">2<\/code> &#8211; the element at index <code style=\"color: #a31515;\">2<\/code> might not be defined! Interestingly, since tuples use numeric literal types for their <code style=\"color: #a31515;\">length<\/code> properties, <code style=\"color: #a31515;\">Coordinate<\/code>&#8216;s <code style=\"color: #a31515;\">length<\/code> property has the type <code style=\"color: #a31515;\">2 | 3<\/code>.<\/p>\n<p>Second, tuples now allow rest elements at the end.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">type OneNumberAndSomeStrings = [number, ...string[]];<\/pre>\n<\/div>\n<p>Rest elements introduce some interesting open-ended behavior to tuples. The above <code style=\"color: #a31515;\">OneNumberAndSomeStrings<\/code> type requires its first property to be a <code style=\"color: #a31515;\">number<\/code>, and permits 0 or more <code style=\"color: #a31515;\">string<\/code>s. Indexing with an arbitrary <code style=\"color: #a31515;\">number<\/code> will return a <code style=\"color: #a31515;\">string | number<\/code> since the index won&#8217;t be known. Likewise, since the tuple length won&#8217;t be known, the <code style=\"color: #a31515;\">length<\/code> property is just <code style=\"color: #a31515;\">number<\/code>.<\/p>\n<p>Of note, when no other elements are present, a rest element in a tuple is identical to itself:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">type Foo = [...number[]]; \/\/ Equivalent to `number[]`.<\/pre>\n<\/div>\n<p>Finally, tuples can now be empty! While it&#8217;s not that useful outside of parameter lists, the empty tuple type can be referenced as <code style=\"color: #a31515;\">[]<\/code>:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">type EmptyTuple = [];<\/pre>\n<\/div>\n<p>As you might expect, the empty tuple has a <code style=\"color: #a31515;\">length<\/code> of <code style=\"color: #a31515;\">0<\/code> and indexing with a <code style=\"color: #a31515;\">number<\/code> returns the <code style=\"color: #a31515;\">never<\/code> type.<\/p>\n<h2 id=\"improved-errors-and-ux\">Improved errors and UX<\/h2>\n<p>Over time we&#8217;ve heard more and more demand from our community regarding better error messages. While we&#8217;re by no means done, we heard you in TypeScript 3.0 and have invested a bit here.<\/p>\n<h3 id=\"related-error-spans\">Related error spans<\/h3>\n<p>Part of the goal of providing a good error message is also guiding a user towards a way to fix the error, or providing a way to intuit why the error message was given in the first place. Much of the time, there can be a lot of information or multiple reasons an error message might surface. Of those reasons, we might find they come from different parts of the code.<\/p>\n<p>Related error spans are a new way to surface that information to users. In TypeScript 3.0, error messages can provide messages on other locations so that users can reason about cause-and-effect of an error.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/11\/2019\/02\/3.0-related-spans-export-default.png\" alt=\"Using import * as express syntax can cause an error when calling express(). Here, the provided error tells the user not just that the call is invalid, but that it has occurred because of the way the user imported express.\" \/><\/p>\n<p>In some sense, related error messages can give a user not just an explanation, but also breadcrumbs to see where things went wrong.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/11\/2019\/02\/3.0-misspelled-related-span1.gif\" alt=\"An error on a potentially misspelled property now also informs the user of where the most likely candidate originated.\" \/><\/p>\n<p>These spans will also appear in the terminal when running <code style=\"color: #a31515;\">tsc<\/code> with <code style=\"color: #a31515;\">--pretty<\/code> mode enabled, though our team is still iterating on the UI and would appreciate feedback!<\/p>\n<h3 id=\"improved-messages-and-elaboration\">Improved messages and elaboration<\/h3>\n<p>Around TypeScript 2.9, we started investing more in our error messages, and <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/25310\">with 3.0 we really tried to tackle a core set of cases<\/a> that could give a smarter, cleaner, and more accurate error experience. This includes things like picking better types with mismatches in union types, and cutting right to the chase for certain error messages.<\/p>\n<p>We believe this effort had paid off and will provide significantly shorter and cleaner error messages.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/11\/2019\/02\/3.0-error-messages-vertical.png\" \/><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/11\/2019\/02\/3.0-error-messages-object-literals-vertical-2.png\" alt=\"Error messages for the equivalent code\/issue in JSX compared between TypeScript 2.8 and TypeScript 3.0. In TypeScript 3.0, the message is dramatically shorter and has a related span, while still providing context.\" \/><\/p>\n<h2 id=\"the-unknown-type\">The <code style=\"color: #a31515; font-size: 29px;\">unknown<\/code> type<\/h2>\n<p>The <code style=\"color: #a31515;\">any<\/code> type is the most-capable type in TypeScript &#8211; while it encompasses the type of every possible value, it doesn&#8217;t force us to do any checking before we try to call, construct, or access properties on these values. It also lets us assign values of type <code style=\"color: #a31515;\">any<\/code> to values that expect any other type.<\/p>\n<p>This is mostly useful, but it can be a bit lax.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">let foo: any = 10;\r\n\r\n\/\/ All of these will throw errors, but TypeScript\r\n\/\/ won't complain since `foo` has the type `any`.\r\nfoo.x.prop;\r\nfoo.y.prop;\r\nfoo.z.prop;\r\nfoo();\r\nnew foo();\r\nupperCase(foo);\r\nfoo `hello world!`;\r\n\r\nfunction upperCase(x: string) {\r\n    return x.toUpperCase();\r\n}<\/pre>\n<\/div>\n<p>There are often times where we want to describe the <em>least<\/em>-capable type in TypeScript. This is useful for APIs that want to signal &#8220;this can be any value, so you <em>must<\/em> perform some type of checking before you use it&#8221;. This forces users to safely introspect returned values.<\/p>\n<p>TypeScript 3.0 introduces a new type called <code style=\"color: #a31515;\">unknown<\/code> that does exactly that. Much like <code style=\"color: #a31515;\">any<\/code>, any value is assignable <em>to<\/em> <code style=\"color: #a31515;\">unknown<\/code>; however, unlike <code style=\"color: #a31515;\">any<\/code>, <code style=\"color: #a31515;\">unknown<\/code> is assignable to almost nothing else without a type assertion. You also can&#8217;t access any properties off of an <code style=\"color: #a31515;\">unknown<\/code>, nor can you call\/construct them.<\/p>\n<p>As an example, swapping the above example to use <code style=\"color: #a31515;\">unknown<\/code> instead of <code style=\"color: #a31515;\">any<\/code> turns all usages of <code style=\"color: #a31515;\">foo<\/code> into an error:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">let foo: unknown = 10;\r\n\r\n\/\/ Since `foo` has type `unknown`, TypeScript\r\n\/\/ errors on each of these locations.\r\nfoo.x.prop;\r\nfoo.y.prop;\r\nfoo.z.prop;\r\nfoo();\r\nnew foo();\r\nupperCase(foo);\r\nfoo `hello world!`;\r\n\r\nfunction upperCase(x: string) {\r\n    return x.toUpperCase();\r\n}<\/pre>\n<\/div>\n<p>Instead, we&#8217;re now forced to either perform checking, or use a type assertion to convince the type-system that we know better.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">let foo: unknown = 10;\r\n\r\nfunction hasXYZ(obj: any): obj is { x: any, y: any, z: any } {\r\n    return !!obj &amp;&amp;\r\n        typeof obj === \"object\" &amp;&amp;\r\n        \"x\" in obj &amp;&amp; \"y\" in obj &amp;&amp; \"z\" in obj\r\n}\r\n\r\n\/\/ Using a user-defined type guard...\r\nif (hasXYZ(foo)) {\r\n    \/\/ ...we're allowed to access certain properties again.\r\n    foo.x.prop;\r\n    foo.y.prop;\r\n    foo.z.prop;\r\n}\r\n\r\n\/\/ We can also just convince TypeScript we know what we're doing\r\n\/\/ by using a type assertion.\r\nupperCase(foo as string);\r\n\r\nfunction upperCase(x: string) {\r\n    return x.toUpperCase();\r\n}<\/pre>\n<\/div>\n<p>Note that if you&#8217;ve been using a type like <code style=\"color: #a31515;\">{} | null | undefined<\/code> to achieve similar behavior, <code style=\"color: #a31515;\">unknown<\/code> usually has more desirable behavior in constructs like conditional types, since conditional types distribute across unions:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">type Arrayify&lt;T&gt; = T extends any ? Array&lt;T&gt; : never;\r\n\r\ntype A = Arrayify&lt;{} | null | undefined&gt;; \/\/ null[] | undefined[] | {}[]\r\ntype B = Arrayify&lt;unknown&gt;;               \/\/ unknown[]<\/pre>\n<\/div>\n<h2 id=\"default-props-support\">Support for <code style=\"color: #a31515; font-size: 29px;\">defaultProps<\/code> in JSX<\/h2>\n<p><em>Note: at the time of writing, React&#8217;s <code style=\"color: #a31515;\">.d.ts<\/code> files may not yet support this functionality.<\/em><\/p>\n<p>If you&#8217;ve ever used default initializers in modern TypeScript\/JavaScript, you might know how handy they can be for function callers. They give us a useful syntax to let callers use functions more easily by not requiring certain arguments, while letting function authors ensure that their values are always defined in a clean way.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function loudlyGreet(name = \"world\") {\r\n    \/\/ Thanks to the default initializer, `name` will always have type `string` internally.\r\n    \/\/ We don't have to check for `undefined` here.\r\n    console.log(\"HELLO\", name.toUpperCase());\r\n}\r\n\r\n\/\/ Externally, `name` is optional, and we can potentially pass `undefined` or omit it entirely.\r\nloudlyGreet();\r\nloudlyGreet(undefined);<\/pre>\n<\/div>\n<p>In <a href=\"https:\/\/reactjs.org\/\" rel=\"nofollow\">React<\/a>, a similar concept exists for components and their <code style=\"color: #a31515;\">props<\/code>. When creating a new element using a component, React looks up a property called <code style=\"color: #a31515;\">defaultProps<\/code>, to fill in values for <code style=\"color: #a31515;\">props<\/code> that are omitted.<\/p>\n<div class=\"highlight highlight-source-js-jsx\">\n<pre class=\"lang:default decode:true\">\/\/ Some non-TypeScript JSX file\r\n\r\nimport * as React from \"react\";\r\nimport * as ReactDOM from \"react-dom\";\r\n\r\nexport class Greet extends React.Component {\r\n    render() {\r\n        const { name } = this.props;\r\n        return &lt;div&gt;Hello ${name.toUpperCase()}!&lt;\/div&gt;;\r\n    }\r\n\r\n    static defaultProps = {\r\n        name: \"world\",\r\n    };\r\n}\r\n\r\n\/\/      Notice no `name` attribute was specified!\r\n\/\/                                     vvvvvvvvv\r\nconst result = ReactDOM.renderToString(&lt;Greet \/&gt;);\r\nconsole.log(result);<\/pre>\n<\/div>\n<p>Notice that in <code style=\"color: #a31515;\">&lt;Greet \/&gt;<\/code>, <code style=\"color: #a31515;\">name<\/code> didn&#8217;t have to be specified. When a <code style=\"color: #a31515;\">Greet<\/code> element is created, <code style=\"color: #a31515;\">name<\/code> will be initialized with <code style=\"color: #a31515;\">\"world\"<\/code> and this code will print <code style=\"color: #a31515;\">&lt;div&gt;Hello world!&lt;\/div&gt;<\/code>.<\/p>\n<p>Unfortunately, TypeScript didn&#8217;t understand that <code style=\"color: #a31515;\">defaultProps<\/code> had any bearing on JSX invocations. Instead, users would often have to declare properties optional and use non-null assertions inside of <code style=\"color: #a31515;\">render<\/code>:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">export interface Props { name?: string }\r\nexport class Greet extends React.Component&lt;Props&gt; {\r\n    render() {\r\n        const { name } = this.props;\r\n\r\n        \/\/ Notice the `!` ------v\r\n        return &lt;div&gt;Hello ${name!.toUpperCase()}!&lt;\/div&gt;;\r\n    }\r\n    static defaultProps = { name: \"world\"}\r\n}<\/pre>\n<\/div>\n<p>Or they&#8217;d use some hacky type-assertions to fix up the type of the component before exporting it.<\/p>\n<p>That&#8217;s why TypeScript 3.0, the language supports a new type alias in the <code style=\"color: #a31515;\">JSX<\/code> namespace called <code style=\"color: #a31515;\">LibraryManagedAttributes<\/code>. Despite the long name, this is just a helper type that tells TypeScript what attributes a JSX tag accepts. The short story is that using this general type, we can model React&#8217;s specific behavior for things like <code style=\"color: #a31515;\">defaultProps<\/code> and, to some extent, <code style=\"color: #a31515;\">propTypes<\/code>.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">export interface Props {\r\n    name: string\r\n}\r\n\r\nexport class Greet extends React.Component&lt;Props&gt; {\r\n    render() {\r\n        const { name } = this.props;\r\n        return &lt;div&gt;Hello ${name.toUpperCase()}!&lt;\/div&gt;;\r\n    }\r\n    static defaultProps = { name: \"world\"}\r\n}\r\n\r\n\/\/ Type-checks! No type assertions needed!\r\nlet el = &lt;Greet \/&gt;<\/pre>\n<\/div>\n<p>Keep in mind that there are some limitations. For <code style=\"color: #a31515;\">defaultProps<\/code> that explicitly specify their type as something like <code style=\"color: #a31515;\">Partial&lt;Props&gt;<\/code>, or stateless function components (SFCs) whose <code style=\"color: #a31515;\">defaultProps<\/code> are declared with <code style=\"color: #a31515;\">Partial&lt;Props&gt;<\/code>, will make <em>all<\/em> props optional. As a workaround, you can omit the type annotation entirely for <code style=\"color: #a31515;\">defaultProps<\/code> on a class component (like we did above), or use ES2015 default initializers for SFCs:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">function Greet({ name = \"world\" }: Props) {\r\n    return &lt;div&gt;Hello ${name.toUpperCase()}!&lt;\/div&gt;;\r\n}<\/pre>\n<\/div>\n<p>One last thing to note is that while the support is built into TypeScript, the current <code style=\"color: #a31515;\">.d.ts<\/code> files on DefinitelyTyped are not <em>currently<\/em> leveraging it &#8211; therefore <code style=\"color: #a31515;\">@types\/react<\/code> may not have the change available yet. We are currently waiting on stabilization throughout DefinitelyTyped to ensure that the change is minimally disruptive.<\/p>\n<h2 id=\"lib-directives\"><code style=\"color: #a31515; font-size: 29px;\">\/\/\/ &lt;reference lib=\"...\" \/&gt;<\/code> directives<\/h2>\n<p>One of the issues we&#8217;ve seen in the community is that polyfills &#8211; libraries that provide newer APIs in older runtimes &#8211; often have their own declaration files (<code style=\"color: #a31515;\">.d.ts<\/code> files) that attempt to define those APIs themselves. While this is sometimes fine, these declarations are global, and may provide issues with TypeScript&#8217;s built-in <code style=\"color: #a31515;\">lib.d.ts<\/code> depending on users&#8217; compiler options like <code style=\"color: #a31515;\">--lib<\/code> and <code style=\"color: #a31515;\">--target<\/code>. For example, declarations for <code style=\"color: #a31515;\">core-js<\/code> might conflict with the built-in <code style=\"color: #a31515;\">lib.es2015.d.ts<\/code>.<\/p>\n<p>To solve this, TypeScript 3.0 provides a new way for files to declare the built-in APIs which they expect to be present using a new reference directive: <code style=\"color: #a31515;\">\/\/\/ &lt;reference lib=\"...\" \/&gt;<\/code>.<\/p>\n<p>For example, a polyfill for ES2015&#8217;s <code style=\"color: #a31515;\">Promise<\/code> might now simply contain the lines<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">\/\/\/ &lt;reference lib=\"es2015.promise\" \/&gt;\r\nexport {};<\/pre>\n<\/div>\n<p>With this comment, even if a TypeScript 3.0 consumer has explicitly used a target that doesn&#8217;t bring in <code style=\"color: #a31515;\">lib.es2015.promise.d.ts<\/code>, importing the above library will ensure that <code style=\"color: #a31515;\">Promise<\/code> is present.<\/p>\n<h2 id=\"editor-productivity\">Editor Productivity<\/h2>\n<p>For those who are unfamiliar, TypeScript leverages its syntactic and semantic knowledge to provide services for writing code more easily. It acts as the engine for TypeScript and JavaScript underneath editors like Visual Studio, Visual Studio Code, and any other editor with a TypeScript plugin to provide the things users love like code completion, <em>Go to Definition<\/em>, and even quick fixes and refactorings. TypeScript 3.0 continues to deliver here.<\/p>\n<h3 id=\"named-import-refactorings\">Named import refactorings<\/h3>\n<p>Occasionally, qualifying every import with the module it came from can be cumbersome.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">import * as dependency from \".\/dependency\";\r\n\r\n\/\/ look at all this repetition!\r\n\r\ndependency.foo();\r\n\r\ndependency.bar();\r\n\r\ndependency.baz();<\/pre>\n<\/div>\n<p>On the other hand, if we individually import the things we use, we might find that after many uses it&#8217;s become unclear for new readers where these imports originated from.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">import { foo, bar, baz } from \".\/dependency\";\r\n\r\n\/\/ way lower in the file...\r\n\r\nfoo();\r\n\r\nbar();\r\n\r\nbaz();<\/pre>\n<\/div>\n<p>Regardless of which you decide to choose now, you might change your mind later. TypeScript 3.0 provides refactorings so that switch never feels daunting.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/11\/2019\/02\/namespaceToNamedImports.gif\" \/><\/p>\n<h3 id=\"jsx-productivity\">Closing JSX tag completions and outlining spans<\/h3>\n<p>TypeScript now provides two new productivity features around JSX:<\/p>\n<ul>\n<li>providing completions for JSX closing tags<\/li>\n<li>providing collapsible outlining spans for JSX<\/li>\n<\/ul>\n<p><img decoding=\"async\" src=\"https:\/\/devblogs.microsoft.com\/typescript\/wp-content\/uploads\/sites\/11\/2019\/02\/jsxCompletionsAndOutlining.gif\" \/><\/p>\n<h3 id=\"remove-bogus-code\">Quick fixes for unreachable code and unused labels<\/h3>\n<p>TypeScript will now provide quick fixes to remove any unreachable code, as well as remove unused labels.<\/p>\n<h2 id=\"breaking-changes\">Breaking changes<\/h2>\n<p>You can always keep an eye on upcoming breaking changes <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/Breaking-Changes\">in the language<\/a> as well as <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/API-Breaking-Changes\/\">in our API<\/a>.<\/p>\n<p>We expect TypeScript 3.0 to have very few impactful breaking changes. Language changes should be minimally disruptive, and most breaks in our APIs are oriented around removing already-deprecated functions.<\/p>\n<h3 id=\"unknown-is-a-reserved-type-name\"><code style=\"color: #a31515; font-size: 26px;\">unknown<\/code> is a reserved type name<\/h3>\n<p>Since <code style=\"color: #a31515;\">unknown<\/code> is a new built-in type, it can no longer be used in type declarations like interfaces, type aliases, or classes.<\/p>\n<h3 id=\"intersecting-with-nullundefined\">Intersecting with <code style=\"color: #a31515; font-size: 26px;\">null<\/code>\/<code style=\"color: #a31515; font-size: 26px;\">undefined<\/code> reduces to <code style=\"color: #a31515; font-size: 26px;\">null<\/code>\/<code style=\"color: #a31515; font-size: 26px;\">undefined<\/code> outside of <code style=\"color: #a31515; font-size: 26px;\">strictNullChecks<\/code><\/h3>\n<p>In the following example, <code style=\"color: #a31515;\">A<\/code> has the type <code style=\"color: #a31515;\">null<\/code> and <code style=\"color: #a31515;\">B<\/code> has the type <code style=\"color: #a31515;\">undefined<\/code> when <code style=\"color: #a31515;\">strictNullChecks<\/code> is turned off:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true  \">type A = { a: number } &amp; null;      \/\/ null\r\ntype B = { a: number } &amp; undefined; \/\/ undefined<\/pre>\n<\/div>\n<p>This is because TypeScript 3.0 is better at reducing subtypes and supertypes in intersection and union types respectively; however, because <code style=\"color: #a31515;\">null<\/code> and <code style=\"color: #a31515;\">undefined<\/code> are both considered subtypes of every other type when <code style=\"color: #a31515;\">strictNullChecks<\/code> is off, an intersection with some object type and either will always reduce to <code style=\"color: #a31515;\">null<\/code> or <code style=\"color: #a31515;\">undefined<\/code>.<\/p>\n<p>If you were relying on <code style=\"color: #a31515;\">null<\/code> and <code style=\"color: #a31515;\">undefined<\/code> to be <a href=\"https:\/\/en.wikipedia.org\/wiki\/Identity_element\" rel=\"nofollow\">&#8220;identity&#8221; elements<\/a> under intersections, you should look for a way to use <code style=\"color: #a31515;\">unknown<\/code> instead of <code style=\"color: #a31515;\">null<\/code> or <code style=\"color: #a31515;\">undefined<\/code> wherever they appeared.<\/p>\n<h3 id=\"api-breaking-changes\">API breaking changes<\/h3>\n<ul>\n<li>The deprecated internal method <code style=\"color: #a31515;\">LanguageService#getSourceFile<\/code> has been removed, as it has been deprecated for two years. See <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/24540\">#24540<\/a>.<\/li>\n<li>The deprecated function <code style=\"color: #a31515;\">TypeChecker#getSymbolDisplayBuilder<\/code> and associated interfaces have been removed. See <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/25331\">#25331<\/a>. The emitter and node builder should be used instead.<\/li>\n<li>The deprecated functions <code style=\"color: #a31515;\">escapeIdentifier<\/code> and <code style=\"color: #a31515;\">unescapeIdentifier<\/code> have been removed. Due to changing how the identifier name API worked in general, they have been identity functions for a few releases, so if you need your code to behave the same way, simply removing the calls should be sufficient. Alternatively, the typesafe <code style=\"color: #a31515;\">escapeLeadingUnderscores<\/code> and <code style=\"color: #a31515;\">unescapeLeadingUnderscores<\/code> should be used if the types indicate they are required (as they are used to convert to or from branded <code style=\"color: #a31515;\">__String<\/code> and <code style=\"color: #a31515;\">string<\/code> types).<\/li>\n<li>The <code style=\"color: #a31515;\">TypeChecker#getSuggestionForNonexistentProperty<\/code>, <code style=\"color: #a31515;\">TypeChecker#getSuggestionForNonexistentSymbol<\/code>, and <code style=\"color: #a31515;\">TypeChecker#getSuggestionForNonexistentModule<\/code> methods have been made internal, and are no longer part of our public API. See <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/25520\">#25520<\/a>.<\/li>\n<\/ul>\n<h1 id=\"going-forward\">Going forward<\/h2>\n<p>TypeScript owes so much of its success to its community. We&#8217;re indebted to our contributors who&#8217;ve worked on the compiler, the language service, DefinitelyTyped, and tooling integration that leveraged any combination of them. But we&#8217;re also grateful for our users who&#8217;ve consistently given us the feedback we needed and pushed us to improve. Going forward, we foresee bringing more value to the type system and tooling experience, polishing the existing work on project references, and making TypeScript (both the language and the project) more approachable by whatever means we can. But in addition to that, we want to explore what we can do to empower more tool authors and users in the JavaScript community &#8211; to bring value to users who could still get value from using TypeScript even without directly using TypeScript.<\/p>\n<p>Keep an eye on <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/Roadmap\">our roadmap<\/a> as these ideas become specifics, and feel free to drop us a line to give us feedback, whether via the comments below, <a href=\"https:\/\/twitter.com\/typescriptlang\/\" rel=\"nofollow\">over Twitter<\/a>, or <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/new\/choose\">by filing an issue<\/a>. We&#8217;re always trying to do better.<\/p>\n<p>For everyone who&#8217;s been a part of the TypeScript journey so far &#8211; thank you. We look forward to bringing you the best experience we can. And for everyone else, we hope you&#8217;ll start exploring and loving TypeScript as much as we do.<\/p>\n<p>Happy hacking!<\/p>\n<p>The TypeScript Team<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>TypeScript 3.0 is here! Today marks a new milestone in the TypeScript journey, serving JavaScript users everywhere.If you&#8217;re unfamiliar with TypeScript, it&#8217;s not too late to learn about it now! TypeScript is an extension of JavaScript that aims to bring static types to modern JavaScript. The TypeScript compiler reads in TypeScript code, which has things [&hellip;]<\/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-1595","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"<p>TypeScript 3.0 is here! Today marks a new milestone in the TypeScript journey, serving JavaScript users everywhere.If you&#8217;re unfamiliar with TypeScript, it&#8217;s not too late to learn about it now! TypeScript is an extension of JavaScript that aims to bring static types to modern JavaScript. The TypeScript compiler reads in TypeScript code, which has things [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1595","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=1595"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1595\/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=1595"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=1595"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=1595"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}