{"id":1683,"date":"2018-07-12T17:02:32","date_gmt":"2018-07-12T17:02:32","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/typescript\/?p=1535"},"modified":"2019-02-27T23:22:40","modified_gmt":"2019-02-28T07:22:40","slug":"announcing-typescript-3-0-rc-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-3-0-rc-2\/","title":{"rendered":"Announcing TypeScript 3.0 RC"},"content":{"rendered":"<div style=\"font-size: 16px;\">\n<p>TypeScript 3.0, our next release of the type system, compiler, and language service, is fast-approaching! Today we&#8217;re excited to announce the Release Candidate of TypeScript 3.0! We&#8217;re looking to get any and all feedback from this RC to successfully ship TypeScript 3.0 proper, so if you&#8217;d like to give it a shot now, you can get the RC <a href=\"https:\/\/www.nuget.org\/packages\/Microsoft.TypeScript.MSBuild\" rel=\"nofollow\">through NuGet<\/a>, or use npm with the following command:<\/p>\n<div class=\"highlight highlight-source-shell\">\n<pre class=\"lang:default decode:true\">npm install -g typescript@rc<\/pre>\n<\/div>\n<p>You can also get editor support by<\/p>\n<ul>\n<li><a href=\"http:\/\/download.microsoft.com\/download\/7\/0\/A\/70A6AC0E-8934-4396-A43E-445059F430EA\/3.0.0-TS-release-dev14update3-20180706.1\/TypeScript_SDK.exe\" rel=\"nofollow\">Downloading for Visual Studio 2017<\/a> (for version 15.2 or later)<\/li>\n<li>Following directions for <a href=\"https:\/\/code.visualstudio.com\/Docs\/languages\/typescript#_using-newer-typescript-versions\" rel=\"nofollow\">Visual Studio Code<\/a> and <a href=\"https:\/\/github.com\/Microsoft\/TypeScript-Sublime-Plugin\/#note-using-different-versions-of-typescript\">Sublime Text<\/a>.<\/li>\n<\/ul>\n<p><em>While Visual Studio 2015 doesn&#8217;t currently have an RC installer, TypeScript 3.0 will be available for Visual Studio 2015 users.<\/em><\/p>\n<p>While you can read about everything <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/Roadmap\">on our Roadmap<\/a>, we&#8217;ll be discussing a few major items going into TypeScript 3.0.<\/p>\n<ul>\n<li><a href=\"#project-references\">Project references<\/a><\/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=\"#default-props-support\">Support for React&#8217;s <code style=\"color: #a31515;\">defaultProps<\/code><\/a><\/li>\n<\/ul>\n<p>Without further ado, let&#8217;s jump into some highlights of the Release Candidate!<\/p>\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>, your Node.js back-end code in a folder called <code style=\"color: #a31515;\">server<\/code>, each which 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<div class=\"highlight highlight-source-js\">\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}<\/pre>\n<\/div>\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 does support 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> 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 <code style=\"color: #a31515;\">.ts<\/code> files and tries to include them in a given compilation. Ideally, TypeScript would understand these files don&#8217;t need to be built in the same compilation, and 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 continuing to improve the experience around editor support using<\/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 call works on functions of any parameter length. Unlike other languages, we don&#8217;t need to define a <code style=\"color: #a31515;\">call1<\/code>, <code style=\"color: #a31515;\">call2<\/code>, <code style=\"color: #a31515;\">call3<\/code> as follows:<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">function 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): 4 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\nfunction call&lt;T1, T2, T3, R&gt;(fn: (param1: T1, param2: T2, param3: T3) =&gt; R, param1: T1, param2: T2, param3: T3);\r\nfunction call&lt;T1, T2, R&gt;(fn: (param1: T1, param2: T2) =&gt; R, param1: T1, param2: T2);\r\nfunction call&lt;T1, R&gt;(fn: (param1: T1) =&gt; R, param1: T1): R;\r\nfunction call(fn: (...args: any[]) =&gt; any, ...args: any[]) {\r\n    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\/\/ `TS` 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>Parameter lists aren&#8217;t just ordered lists of types. 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>And the final 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>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=\"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>, you cannot access any properties on values with the type <code style=\"color: #a31515;\">unknown<\/code>, nor can you call\/construct them. Furthermore, values of type <code style=\"color: #a31515;\">unknown<\/code> can <em>only<\/em> be assigned to <code style=\"color: #a31515;\">unknown<\/code> or <code style=\"color: #a31515;\">any<\/code>.<\/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> forces 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 usages.\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;\r\n        \"y\" in obj &amp;&amp;\r\n        \"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<h2 id=\"default-props-support\">Support for <code style=\"color: #a31515; font-size: 29px;\">defaultProps<\/code> in JSX<\/h2>\n<p>Default initializers are a handy feature in modern TypeScript\/JavaScript. 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 React looks up a property called <code style=\"color: #a31515;\">defaultProps<\/code> to fill in any <code style=\"color: #a31515;\">props<\/code> that were 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<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=\"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<h2 id=\"whats-next\">What&#8217;s next?<\/h2>\n<p>Since we always keep <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/Roadmap\">our Roadmap<\/a> up-to-date, you can get a picture of what else is in store for TypeScript 3.0 and beyond there.<\/p>\n<p>TypeScript 3.0 is meant to be a foundational release for project references and other powerful type system constructs. We expect it to be available at the end of the month, so until then we&#8217;ll be polishing off the release so that you can have the smoothest experience possible. In the meantime, we would love and appreciate any feedback from this RC so we can bring you that experience. Everything we do in TypeScript is driven by our users&#8217; needs, so any contribution you can make by just trying out this release candidate would go a long way.<\/p>\n<p>So feel free to <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/new\">drop us a line on GitHub if you run into any problems<\/a>, and let others know how you feel about this RC on Twitter and in the comments below!<\/p>\n<p>Happy hacking!<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>TypeScript 3.0, our next release of the type system, compiler, and language service, is fast-approaching! Today we&#8217;re excited to announce the Release Candidate of TypeScript 3.0! We&#8217;re looking to get any and all feedback from this RC to successfully ship TypeScript 3.0 proper, so if you&#8217;d like to give it a shot now, you can [&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-1683","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"<p>TypeScript 3.0, our next release of the type system, compiler, and language service, is fast-approaching! Today we&#8217;re excited to announce the Release Candidate of TypeScript 3.0! We&#8217;re looking to get any and all feedback from this RC to successfully ship TypeScript 3.0 proper, so if you&#8217;d like to give it a shot now, you can [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1683","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=1683"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/1683\/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=1683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=1683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=1683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}