{"id":2107,"date":"2018-11-29T09:00:14","date_gmt":"2018-11-29T17:00:14","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=2107"},"modified":"2019-02-27T21:08:04","modified_gmt":"2019-02-28T05:08:04","slug":"announcing-typescript-3-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-3-2\/","title":{"rendered":"Announcing TypeScript 3.2"},"content":{"rendered":"<div style=\"font-size: 16px;\">TypeScript 3.2 is here today!If you&#8217;re unfamiliar with TypeScript, it&#8217;s a language that brings static type-checking to JavaScript so that you can catch issues before you even run your code &#8211; or before you even save your file. It also includes the latest JavaScript features from the ECMAScript standard on older browsers and runtimes by compiling those features into a form that they understand. But beyond type-checking and compiling your code, TypeScript also provides tooling in your favorite editor so that you can jump to the definition of any variable, find who&#8217;s using a given function, and automate refactorings and fixes to common problems. TypeScript even provides this for JavaScript users (and can also type-check JavaScript code typed with JSDoc), so if you&#8217;ve used editors like Visual Studio or Visual Studio Code on a <code style=\"color: #a31515;\">.js<\/code> file, TypeScript is powering that experience.<\/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.<\/p>\n<p>But if you want to try TypeScript 3.2 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>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.2.1-TS-release-dev14-update3-20181129.3\/TypeScript_SDK.exe\">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.2.1-TS-release-dev14-update3-20181129.3\/TypeScript_Dev14Full.exe\">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 TypeScript available soon.<\/p>\n<p>We have <a href=\"#a-note-for-nuget-and-visual-studio-2015\">some important information below for NuGet users and Visual Studio 2015 users<\/a>, so please continue reading if you use either product.<\/p>\n<p>Below we have a bit about what&#8217;s new in 3.2.<\/p>\n<ul>\n<li><a href=\"#strictbindcallapply\"><code style=\"color: #a31515;\">strictBindCallApply<\/code><\/a><\/li>\n<li><a href=\"#object-spread-on-generic-types\">Object spread on generic types<\/a><\/li>\n<li><a href=\"#object-rest-on-generic-types\">Object rest on generic types<\/a><\/li>\n<li><a href=\"#configuration-inheritance-via-node_modules-packages\">Node.js-based resolution for <code style=\"color: #a31515;\">tsconfig.json<\/code> inheritance<\/a><\/li>\n<li><a href=\"#diagnosing-tsconfigjson-with---showconfig\">Diagnosing <code style=\"color: #a31515;\">tsconfig.json<\/code> with <code style=\"color: #a31515;\">--showConfig<\/code><\/a><\/li>\n<li><a href=\"#bigint\">BigInt<\/a><\/li>\n<li><a href=\"#objectdefineproperty-declarations-in-javascript\"><code style=\"color: #a31515;\">Object.defineProperty<\/code> declarations in JavaScript<\/a><\/li>\n<li><a href=\"#error-message-improvements\">Error message improvements<\/a><\/li>\n<li><a href=\"#improved-narrowing-for-tagged-unions\">Improved narrowing for tagged unions<\/a><\/li>\n<li><a href=\"#editing-improvements\">Editing improvements<\/a><\/li>\n<li><a href=\"#breaking-changes-and-deprecations\">Breaking changes and deprecations<\/a>\n<ul>\n<li><a href=\"#a-note-for-nuget-and-visual-studio-2015\">A note for NuGet and Visual Studio 2015 users<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#whats-next\">What&#8217;s next<\/a><\/li>\n<\/ul>\n<h2 id=\"strictbindcallapply\"><code style=\"color: #a31515; font-size: 29px;\">strictBindCallApply<\/code><\/h2>\n<p>As you might&#8217;ve guessed from the title of this section, TypeScript 3.2 introduces stricter checking for <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code>. But what does that mean?<\/p>\n<p>Well, in JavaScript, <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code> are methods on functions that allow us to do things like bind <code style=\"color: #a31515;\">this<\/code> and partially apply arguments, call functions with a different value for <code style=\"color: #a31515;\">this<\/code>, and call functions with an array for their arguments.<\/p>\n<p>Unfortunately, in its earlier days, TypeScript lacked the power to model these functions, and <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code> were all typed to take any number of arguments and returned <code style=\"color: #a31515;\">any<\/code>. Additionally, ES2015&#8217;s arrow functions and rest\/spread arguments gave us a new syntax that made it easier to express what some of these methods do &#8211; and in a more efficient way as well.<\/p>\n<p>Still, demand to model these patterns in a type-safe way led us to revisit this problem recently. We realized that two features opened up the right abstractions to accurately type <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code> without any hard-coding:<\/p>\n<ol>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/6739\"><code style=\"color: #a31515;\">this<\/code> parameter types<\/a> from TypeScript 2.0<\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/24897\">Modeling parameter lists with tuple types<\/a> from TypeScript 3.0<\/li>\n<\/ol>\n<p>Combined, the two of of them can ensure our uses of <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code> are more strictly checked when we use a new flag called <code style=\"color: #a31515;\">strictBindCallApply<\/code>. When using this new flag, the methods on callable objects are described by a new global type called <code style=\"color: #a31515;\">CallableFunction<\/code> which declares stricter versions of the signatures for <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code>. Similarly, any methods on constructable (but not callable) objects are described by a new global type called <code style=\"color: #a31515;\">NewableFunction<\/code>.<\/p>\n<p>As an example, we can look at how <code style=\"color: #a31515;\">Function.prototype.apply<\/code> acts under this behavior:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">function foo(a: number, b: string): string {\r\n    return a + b;\r\n}\r\n\r\nlet a = foo.apply(undefined, [10]);              \/\/ error: too few argumnts\r\nlet b = foo.apply(undefined, [10, 20]);          \/\/ error: 2nd argument is a number\r\nlet c = foo.apply(undefined, [10, \"hello\", 30]); \/\/ error: too many arguments\r\nlet d = foo.apply(undefined, [10, \"hello\"]);     \/\/ okay! returns a string<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>Needless to say, whether you do any sophisticated metaprogramming, or you use simple patterns like binding methods in your class instances (<code style=\"color: #a31515;\">this.foo = this.foo.bind(this)<\/code>), this feature can help catch a lot of bugs. For more details, you can check out <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/27028\">the original pull request here<\/a>.<\/p>\n<h3>Caveats<\/h3>\n<p><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/27028#issuecomment-429334450\">One caveat<\/a> of this new functionality is that due to certain limitations, <code style=\"color: #a31515;\">bind<\/code>, <code style=\"color: #a31515;\">call<\/code>, and <code style=\"color: #a31515;\">apply<\/code> can&#8217;t yet fully model generic functions or functions that have overloads. When using these methods on a generic function, type parameters will be substituted with the empty object type (<code style=\"color: #a31515;\">{}<\/code>), and when used on a function with overloads, only the last overload will ever be modeled.<\/p>\n<h2 id=\"object-spread-on-generic-types\">Object spread on generic types<\/h2>\n<p>JavaScript supports a handy way of copying existing properties from an existing object into a new one called &#8220;spreads&#8221;. To spread an existing object into a new object, you define an element with three consecutive periods (<code style=\"color: #a31515;\">...<\/code>) like so:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">let person = { name: \"Daniel\", location: \"New York City\" };\r\n\r\n\/\/ My secret revealed, I have two clones!\r\nlet shallowCopyOfPerson = { ...person };\r\nlet shallowCopyOfPersonWithDifferentLocation = { ...person, location: \"Seattle\" };\r\nTypeScript does a pretty good job here when it has enough information about the type. The type system closely tries to model the behavior of spreads and overwrites new properties, tries to ignore methods, etc. But unfortunately up until now it wouldn't work with generics at all.\r\n\r\nfunction merge&lt;T, U&gt;(x: T, y: U) {\r\n    \/\/ Previously an error!\r\n    return { ...x, ...y };\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>This was an error because we had no way to express the return type of <code style=\"color: #a31515;\">merge<\/code>. There was no syntax (nor semantics) that could express two unknown types being spread into a new one.<\/p>\n<p>We could have come up with a new concept in the type system called an &#8220;object spread type&#8221;, and in fact <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/10727\">we had a proposal for exactly that<\/a>. Essentially this would be a new type operator that looks like <code style=\"color: #a31515;\">{ ...T, ...U }<\/code> to reflect the syntax of an object spread.\nWhen both <code style=\"color: #a31515;\">T<\/code> and <code style=\"color: #a31515;\">U<\/code> are known, that type would flatten down to some new object type.<\/p>\n<p>However, this is pretty complex and requires adding new rules to type relationships and inference. While we explored several different avenues, we recently arrived at two conclusions:<\/p>\n<ol>\n<li>For most uses of spreads in JavaScript, users were fine modeling the behavior with intersection types (i.e. <code style=\"color: #a31515;\">Foo &amp; Bar<\/code>).<\/li>\n<li><code style=\"color: #a31515;\">Object.assign<\/code> &#8211; a function that exhibits most of the behavior of spreading objects &#8211; is already modeled using intersection types, and we&#8217;ve seen very little negative feedback around that.<\/li>\n<\/ol>\n<p>Given that intersections model the common cases, and that they&#8217;re relatively easy to reason about for both users and the type system, TypeScript 3.2 now permits object spreads on generics and models them using intersections:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">\/\/ Returns 'T &amp; U'\r\nfunction merge&lt;T, U&gt;(x: T, y: U) {\r\n    return { ...x, ...y };\r\n}\r\n\r\n\/\/ Returns '{ name: string, age: number, greeting: string } &amp; T'\r\nfunction foo&lt;T&gt;(obj: T) {\r\n    let person = {\r\n        name: \"Daniel\",\r\n        age: 26\r\n    };\r\n\r\n    return { ...person, greeting: \"hello\", ...obj };\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<h2 id=\"object-rest-on-generic-types\">Object rest on generic types<\/h2>\n<p>Object rest patterns are sort of the dual of object spreads. Instead of creating a new object with some extra\/overridden properties, it creates a new object that <em>lacks<\/em> some specified properties.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true\">let { x, y, z, ...rest } = obj;<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>In the above, the most intuitive way to look at this code is that <code style=\"color: #a31515;\">rest<\/code> copies over all the properties from <code style=\"color: #a31515;\">obj<\/code> <em>apart<\/em> from <code style=\"color: #a31515;\">x<\/code>, <code style=\"color: #a31515;\">y<\/code>, and <code style=\"color: #a31515;\">z<\/code>. For the same reason as above, because we didn&#8217;t have a good way to describe the type of <code style=\"color: #a31515;\">rest<\/code> when <code style=\"color: #a31515;\">obj<\/code> is generic, we didn&#8217;t support this for a while.<\/p>\n<p>Here we also considered a new rest operator, but we saw we already had the facilities for describing the above: our <code style=\"color: #a31515;\">Pick<\/code> and <code style=\"color: #a31515;\">Exclude<\/code> helper types in <code style=\"color: #a31515;\">lib.d.ts<\/code> To reiterate, <code style=\"color: #a31515;\">...rest<\/code> basically picks off all of the properties on <code style=\"color: #a31515;\">obj<\/code> except for <code style=\"color: #a31515;\">x<\/code>, <code style=\"color: #a31515;\">y<\/code>, and <code style=\"color: #a31515;\">z<\/code> in the following example:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">interface XYZ { x: any; y: any; z: any; }\r\n\r\nfunction dropXYZ&lt;T extends XYZ&gt;(obj: T) {\r\n    let { x, y, z, ...rest } = obj;\r\n    return rest;\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>If we want to consider the properties of <code style=\"color: #a31515;\">T<\/code> (i.e. <code style=\"color: #a31515;\">keyof T<\/code>) except for <code style=\"color: #a31515;\">x<\/code>, <code style=\"color: #a31515;\">y<\/code>, and <code style=\"color: #a31515;\">z<\/code>, we can write <code style=\"color: #a31515;\">Exclude&lt;keyof T, \"x\" | \"y\" | \"z\"&gt;<\/code>. We then want to pick those properties back off of the original type <code style=\"color: #a31515;\">T<\/code>, which gives us<\/p>\n<div class=\"highlight highlight-text-roff\">\n<pre class=\"lang:default decode:true\">Pick&lt;T, Exclude&lt;keyof T, \"x\" | \"y\" | \"z\"&gt;&gt;`.<\/pre>\n<\/div>\n<p>While it&#8217;s not the most beautiful type (hey, I&#8217;m no George Clooney myself), we can wrap it in a helper type like <code style=\"color: #a31515;\">DropXYZ<\/code>:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">interface XYZ { x: any; y: any; z: any; }\r\n\r\ntype DropXYZ&lt;T&gt; = Pick&lt;T, Exclude&lt;keyof T, keyof XYZ&gt;&gt;;\r\n\r\nfunction dropXYZ&lt;T extends XYZ&gt;(obj: T): DropXYZ&lt;T&gt; {\r\n    let { x, y, z, ...rest } = obj;\r\n    return rest;\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<h2><\/h2>\n<h2>Configuration inheritance via <code style=\"color: #a31515; font-size: 29px;\">node_modules<\/code> packages<\/h2>\n<p>For a long time TypeScript has supported extending <code style=\"color: #a31515;\">tsconfig.json<\/code> files using the <code style=\"color: #a31515;\">extends<\/code> field.<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">{\r\n    \"extends\": \"..\/tsconfig-base.json\",\r\n    \"include\": [\".\/**\/*\"]\r\n    \"compilerOptions\": {\r\n        \/\/ Override certain options on a project-by-project basis.\r\n        \"strictBindCallApply\": false,\r\n    }\r\n}<\/pre>\n<\/div>\n<p>This feature is very useful to avoid duplicating configuration which can easiy fall our of sync, but it really works best when multiple projects are co-located in the same respository so that each project can reference a common &#8220;base&#8221; <code style=\"color: #a31515;\">tsconfig.json<\/code>.<\/p>\n<p>But for some teams, projects are written and published as completely independent packages. Those projects don&#8217;t have a common file they can reference, so as a workaround, users could create a separate package and reference that:<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">{\r\n    \"extends\": \"..\/node_modules\/@my-team\/tsconfig-base\/tsconfig.json\",\r\n    \"include\": [\".\/**\/*\"]\r\n    \"compilerOptions\": {\r\n        \/\/ Override certain options on a project-by-project basis.\r\n        \"strictBindCallApply\": false,\r\n    }\r\n}<\/pre>\n<\/div>\n<p>However, climbing up parent directories with a series of leading <code style=\"color: #a31515;\">..\/<\/code>s and reaching directly into <code style=\"color: #a31515;\">node_modules<\/code> to grab a specific file feels unwieldy.<\/p>\n<p>TypeScript 3.2 now resolves <code style=\"color: #a31515;\">tsconfig.json<\/code>s from <code style=\"color: #a31515;\">node_modules<\/code>. When using a bare path for the <code style=\"color: #a31515;\">\"extends\"<\/code> field in <code style=\"color: #a31515;\">tsconfig.json<\/code>, TypeScript will dive into <code style=\"color: #a31515;\">node_modules<\/code> packages for us.<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true\">{\r\n    \"extends\": \"@my-team\/tsconfig-base\",\r\n    \"include\": [\".\/**\/*\"]\r\n    \"compilerOptions\": {\r\n        \/\/ Override certain options on a project-by-project basis.\r\n        \"strictBindCallApply\": false,\r\n    }\r\n}<\/pre>\n<\/div>\n<p>Here, TypeScript will climb up <code style=\"color: #a31515;\">node_modules<\/code> folders looking for a <code style=\"color: #a31515;\">@my-team\/tsconfig-base<\/code> package. For each of those packages, TypeScript will first check whether <code style=\"color: #a31515;\">package.json<\/code> contains a <code style=\"color: #a31515;\">\"tsconfig\"<\/code> field, and if it does, TypeScript will try to load a configuration file from that field. If neither exists, TypeScript will try to read from a <code style=\"color: #a31515;\">tsconfig.json<\/code> at the root. This is similar to the lookup process for <code style=\"color: #a31515;\">.js<\/code> files in packages that Node uses, and the <code style=\"color: #a31515;\">.d.ts<\/code> lookup process that TypeScript already uses.<\/p>\n<p>This feature can be extremely useful for bigger organizations, or projects with lots of distributed dependencies.<\/p>\n<h2 id=\"diagnosing-tsconfigjson-with---showconfig\">Diagnosing <code style=\"color: #a31515; font-size: 29px;\">tsconfig.json<\/code> with <code style=\"color: #a31515; font-size: 29px;\">--showConfig<\/code><\/h2>\n<p><code style=\"color: #a31515;\">tsc<\/code>, the TypeScript compiler, supports a new flag called <code style=\"color: #a31515;\">--showConfig<\/code>. When running <code style=\"color: #a31515;\">tsc --showConfig<\/code>, TypeScript will calculate the effective <code style=\"color: #a31515;\">tsconfig.json<\/code> (after calculating options inherited from the <code style=\"color: #a31515;\">extends<\/code> field) and print that out. This can be useful for diagnosing configuration issues in general.<\/p>\n<h2 id=\"bigint\">BigInt<\/h2>\n<p>BigInts are part of an upcoming proposal in ECMAScript that allow us to model theoretically arbitrarily large integers. TypeScript 3.2 brings type-checking for BigInts, as well as support for emitting BigInt literals when targeting <code style=\"color: #a31515;\">esnext<\/code>.<\/p>\n<p>BigInt support in TypeScript introduces a new primitive type called the <code style=\"color: #a31515;\">bigint<\/code> (all lowercase). You can get a <code style=\"color: #a31515;\">bigint<\/code> by calling the <code style=\"color: #a31515;\">BigInt()<\/code> function or by writing out a BigInt literal by adding an <code style=\"color: #a31515;\">n<\/code> to the end of any integer numeric literal:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">let foo: bigint = BigInt(100); \/\/ the BigInt function\r\nlet bar: bigint = 100n;        \/\/ a BigInt literal\r\n\r\n\/\/ *Slaps roof of fibonacci function*\r\n\/\/ This bad boy returns ints that can get *so* big!\r\nfunction fibonacci(n: bigint) {\r\n    let result = 1n;\r\n    for (let last = 0n, i = 0n; i &lt; n; i++) {\r\n        const current = result;\r\n        result += last;\r\n        last = current;\r\n    }\r\n    return result;\r\n}\r\n\r\nfibonacci(10000n)<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>While you might imagine close interaction between <code style=\"color: #a31515;\">number<\/code> and <code style=\"color: #a31515;\">bigint<\/code>, the two are separate domains.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">declare let foo: number;\r\ndeclare let bar: bigint;\r\n\r\nfoo = bar; \/\/ error: Type 'bigint' is not assignable to type 'number'.\r\nbar = foo; \/\/ error: Type 'number' is not assignable to type 'bigint'.\r\nAs specified in ECMAScript, mixing numbers and bigints in arithmetic operations is an error. You'll have to explicitly convert values to BigInts.\r\n\r\nconsole.log(3.141592 * 10000n);     \/\/ error\r\nconsole.log(3145 * 10n);            \/\/ error\r\nconsole.log(BigInt(3145) * 10n);    \/\/ okay!<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>Also important to note is that <code style=\"color: #a31515;\">bigint<\/code>s produce a new string when using the <code style=\"color: #a31515;\">typeof<\/code> operator: the string <code style=\"color: #a31515;\">\"bigint\"<\/code>. Thus, TypeScript correctly narrows using <code style=\"color: #a31515;\">typeof<\/code> as you&#8217;d expect.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">function whatKindOfNumberIsIt(x: number | bigint) {\r\n    if (typeof x === \"bigint\") {\r\n        console.log(\"'x' is a bigint!\");\r\n    }\r\n    else {\r\n        console.log(\"'x' is a floating-point number\");\r\n    }\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<p>We&#8217;d like to extend a huge thanks to <a href=\"https:\/\/github.com\/calebsander\">Caleb Sander<\/a> for all the work on this feature. We&#8217;re grateful for the contribution, and we&#8217;re sure our users are too!<\/p>\n<h3>Caveats<\/h3>\n<p>As we mentioned, BigInt support is only available for the <code style=\"color: #a31515;\">esnext<\/code> target. It may not be obvious, but because BigInts have different behavior for mathematical operators like <code style=\"color: #a31515;\">+<\/code>, <code style=\"color: #a31515;\">-<\/code>, <code style=\"color: #a31515;\">*<\/code>, etc., providing functionality for older targets where the feature doesn&#8217;t exist (like <code style=\"color: #a31515;\">es2017<\/code> and below) would involve rewriting each of these operations. TypeScript would need to dispatch to the correct behavior depending on the type, and so every addition, string concatenation, multiplication, etc. would involve a function call.<\/p>\n<p>For that reason, we have no immediate plans to provide downleveling support. On the bright side, Node 11 and newer versions of Chrome already support this feature, so you&#8217;ll be able to use BigInts there when targeting <code style=\"color: #a31515;\">esnext<\/code>.<\/p>\n<p>Certain targets may include a polyfill or BigInt-like runtime object. For those purposes you may want to add <code style=\"color: #a31515;\">esnext.bigint<\/code> to the <code style=\"color: #a31515;\">lib<\/code> setting in your compiler options.<\/p>\n<h2 id=\"objectdefineproperty-declarations-in-javascript\"><code style=\"color: #a31515; font-size: 29px;\">Object.defineProperty<\/code> declarations in JavaScript<\/h2>\n<p>When writing in JavaScript files (using <code style=\"color: #a31515;\">allowJs<\/code>), TypeScript now recognizes declarations that use <code style=\"color: #a31515;\">Object.defineProperty<\/code>. This means you&#8217;ll get better completions, and stronger type-checking when enabling type-checking in JavaScript files (by turning on the <code style=\"color: #a31515;\">checkJs<\/code> option or adding a <code style=\"color: #a31515;\">\/\/ @ts-check<\/code> comment to the top of your file).<\/p>\n<div class=\"highlight highlight-source-js\">\n<pre class=\"lang:default decode:true \">\/\/ @ts-check\r\n\r\nlet obj = {};\r\nObject.defineProperty(obj, \"x\", { value: \"hello\", writable: false });\r\n\r\nobj.x.toLowercase();\r\n\/\/    ~~~~~~~~~~~\r\n\/\/    error:\r\n\/\/     Property 'toLowercase' does not exist on type 'string'.\r\n\/\/     Did you mean 'toLowerCase'?\r\n\r\nobj.x = \"world\";\r\n\/\/  ~\r\n\/\/  error:\r\n\/\/   Cannot assign to 'x' because it is a read-only property.<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<h2 id=\"error-message-improvements\">Error message improvements<\/h2>\n<p>We&#8217;re continuing to push improvements in the error experience in TypeScript. Here&#8217;s a few things in TypeScript 3.2 that we believe will make the language easier to use.<\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/26423\">Better missing property errors (and cleaner missing attributes in JSX)<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/27030\">Better error spans in arrays and arrow functions<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/26450\">Error on most-overlapping types in unions (a.k.a. &#8220;pick most overlappy type&#8221;)<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/26461\">Related spans when a typed <code style=\"color: #a31515;\">this<\/code> is shadowed<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/26991\">&#8220;Did you forget a semicolon?&#8221; on parenthesized expressions on the next line<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/28297\">More specific messages when assigning to <code style=\"color: #a31515;\">const<\/code>\/<code style=\"color: #a31515;\">readonly<\/code> bindings<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/27890\">More accurate message when extending complex types<\/a><\/li>\n<li><a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/25747\">Use relative module names in error messages<\/a><\/li>\n<\/ul>\n<p>Thanks to <a href=\"https:\/\/github.com\/Kingwl\">Kingwl<\/a>, <a href=\"https:\/\/github.com\/a-tarasyuk\">a-tarasyuk<\/a>, and <a href=\"https:\/\/github.com\/prateekgoel\">prateekgoel<\/a> who helped out on some of these improvements.<\/p>\n<h2 id=\"improved-narrowing-for-tagged-unions\">Improved narrowing for tagged unions<\/h2>\n<p>TypeScript 3.2 makes narrowing easier by relaxing rules for what&#8217;s considered a discriminant property. Common properties of unions are now considered discriminants as long as they contain <em>some<\/em> singleton type (e.g. a string literal, <code style=\"color: #a31515;\">null<\/code>, or <code style=\"color: #a31515;\">undefined<\/code>), and they contain no generics.<\/p>\n<p>As a result, TypeScript 3.2 considers the <code style=\"color: #a31515;\">error<\/code> property in the following example to be a discriminant, whereas before it wouldn&#8217;t since <code style=\"color: #a31515;\">Error<\/code> isn&#8217;t a singleton type. Thanks to this, narrowing works correctly in the body of the <code style=\"color: #a31515;\">unwrap<\/code> function.<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">type Either&lt;T&gt; =\r\n    | { error: Error; data: null }\r\n    | { error: null; data: T };\r\n\r\nfunction unwrap&lt;T&gt;(result: Either&lt;T&gt;) {\r\n    if (result.error) {\r\n        \/\/ Here 'error' is non-null\r\n        throw result.error;\r\n    }\r\n\r\n    \/\/ Now 'data' is non-null\r\n    return result.data;\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<h2 id=\"editing-improvements\">Editing improvements<\/h2>\n<p>The TypeScript project doesn&#8217;t simply consist of a compiler\/type-checker. The core components of the compiler also provide a cross-platform open-source language service that can power &#8220;smarter&#8221; editor features like go-to-definition, find-all-references, and a number of quick fixes and refactorings. TypeScript 3.2 brings some small quality of life improvements.<\/p>\n<h3 id=\"quick-fixes\">Quick fixes<\/h3>\n<h4 id=\"implicit-any-suggestions-and-infer-from-usage-fixes\">Implicit <code style=\"color: #a31515; font-size: 23px;\">any<\/code> suggestions and &#8220;infer from usage&#8221; fixes<\/h4>\n<p>We strongly suggest users take advantage of stricter checking when possible. <code style=\"color: #a31515;\">noImplicitAny<\/code> is one of these stricter checking modes, and it helps ensure that your code is as fully typed as possible which also leads to a better editing experience.<\/p>\n<p>Unfortunately it&#8217;s not all roses for existing codebases. <code style=\"color: #a31515;\">noImplicitAny<\/code> is a big switch across codebases which can lead to a lot of error messages and red squiggles in your editor as you type code. The experience can be jarring to turn on just to find out which variables need types.<\/p>\n<p>In this release, TypeScript produces <em>suggestions<\/em> for most variables and parameters that would have been reported as having implicit <code style=\"color: #a31515;\">any<\/code> types. When an editor reports these suggestions, TypeScript also provides a quick fix to automatically infer the types for you.<\/p>\n<p><a href=\"https:\/\/camo.githubusercontent.com\/ec3205227e91264a53ed98270a3ef6e0ea187aad\/68747470733a2f2f6d73646e7368617265642e626c6f622e636f72652e77696e646f77732e6e65742f6d656469612f323031382f31312f6e6f496d706c69636974416e794572726f7273576974684e6f4e6f496d706c69636974416e792e676966\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" src=\"https:\/\/msdnshared.blob.core.windows.net\/media\/2018\/11\/noImplicitAnyErrorsWithNoNoImplicitAny.gif\" alt=\"Types automatically filled in for implicit any parameters.\" \/><\/a><\/p>\n<p>This can make migrating an existing codebase to TypeScript even easier, and we expect it will make migrating to <code style=\"color: #a31515;\">noImplicitAny<\/code> a breeze.<\/p>\n<p>Going a step further, TypeScript users who are type-checking their <code style=\"color: #a31515;\">.js<\/code> files using <code style=\"color: #a31515;\">checkJs<\/code> or the <code style=\"color: #a31515;\">\/\/ @ts-check<\/code> comments can now also get the same functionality with JSDoc types!<\/p>\n<p><a href=\"https:\/\/camo.githubusercontent.com\/824561330e21666bafda21cb608c9a9aa05f143a\/68747470733a2f2f6d73646e7368617265642e626c6f622e636f72652e77696e646f77732e6e65742f6d656469612f323031382f31312f6a73446f63496d706c69636974416e794669782e676966\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" src=\"https:\/\/msdnshared.blob.core.windows.net\/media\/2018\/11\/jsDocImplicitAnyFix.gif\" alt=\"Automatically generating JSDoc types for implicit any parameters in JavaScript files.\" \/><\/a><\/p>\n<h4 id=\"other-fixes\">Other fixes<\/h4>\n<p>TypeScript 3.2 also brings two smaller quick fixes for small mistakes.<\/p>\n<ul>\n<li>Add a missing <code style=\"color: #a31515;\">new<\/code> when accidentally calling a constructor.<\/li>\n<li>Add an intermediate assertion to <code style=\"color: #a31515;\">unknown<\/code> when types are sufficiently unrelated.<\/li>\n<\/ul>\n<p>Thanks to GitHub users <a href=\"https:\/\/github.com\/iliashkolyar\">iliashkolyar<\/a> and <a href=\"https:\/\/github.com\/ryanclarke\">ryanclarke<\/a> respectively for these changes!<\/p>\n<h3 id=\"improved-formatting\">Improved formatting<\/h3>\n<p>Thanks to <a href=\"https:\/\/github.com\/saschanaz\">saschanaz<\/a>, TypeScript is now smarter about formatting several different constructs. Listing all of them might be a bit cumbersome, but you can take a look at the pull request <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/pull\/28340\">here<\/a>.<\/p>\n<h2 id=\"breaking-changes-and-deprecations\">Breaking changes and deprecations<\/h2>\n<h3 id=\"libdts-changes\"><code style=\"color: #a31515; font-size: 26px;\">lib.d.ts<\/code> changes<\/h3>\n<p>TypeScript has recently moved more to generating DOM declarations in <code style=\"color: #a31515;\">lib.d.ts<\/code> by leveraging IDL files provided by standards groups. Upgraders should note take note of any issues they encounter related to the DOM and <a href=\"https:\/\/github.com\/Microsoft\/TSJS-lib-generator\/\">report them<\/a>.<\/p>\n<h4 id=\"more-specific-types\">More specific types<\/h4>\n<p>Certain parameters no longer accept <code style=\"color: #a31515;\">null<\/code>, or now accept more specific types as per the corresponding specifications that describe the DOM.<\/p>\n<h4 id=\"more-platform-specific-deprecations\">More platform-specific deprecations<\/h4>\n<p>Certain properties that are WebKit-specific have been deprecated. They are likely to be removed in a new version.<\/p>\n<h4 id=\"wheeldelta-and-friends-have-been-removed\"><code style=\"color: #a31515; font-size: 23px;\">wheelDelta<\/code> and friends have been removed.<\/h4>\n<p><code style=\"color: #a31515;\">wheelDeltaX<\/code>, <code style=\"color: #a31515;\">wheelDelta<\/code>, and <code style=\"color: #a31515;\">wheelDeltaZ<\/code> have all been removed as they are deprecated properties on <code style=\"color: #a31515;\">WheelEvent<\/code>s.<\/p>\n<p>As a solution, you can use <code style=\"color: #a31515;\">deltaX<\/code>, <code style=\"color: #a31515;\">deltaY<\/code>, and <code style=\"color: #a31515;\">deltaZ<\/code> instead. If older runtimes are a concern, you can include a file called <code style=\"color: #a31515;\">legacy.d.ts<\/code> in your project and write the following in it:<\/p>\n<div class=\"highlight highlight-source-ts\">\n<pre class=\"lang:default decode:true \">\/\/ legacy.d.ts\r\n\r\ninterface WheelEvent {\r\n     readonly wheelDelta: number;\r\n     readonly wheelDeltaX: number;\r\n     readonly wheelDeltaZ: number;\r\n}<\/pre>\n<p>&nbsp;<\/p>\n<\/div>\n<h3 id=\"jsx-resolution-changes\">JSX resolution changes<\/h3>\n<p>Our logic for resolving JSX invocations has been unified with our logic for resolving function calls. While this has simplified the compiler codebase and improved some use-cases, there may be some differences which we may need to reconcile. These changes are likely unintentional so they are not breaking changes <em>per se<\/em>, but upgraders should note take note of any issues they encounter and <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/new\/choose\">report them<\/a>.<\/p>\n<h2 id=\"a-note-for-nuget-and-visual-studio-2015\">A note for NuGet and Visual Studio 2015<\/h2>\n<p>We have some changes coming in TypeScript 3.2 for NuGet and VS2015 users.<\/p>\n<p>First, TypeScript 3.2 and future releases will only ship an MSBuild package, and not a standalone compiler package. Second, while our NuGet packages previously shipped with the Chakra JavaScript engine to run the compiler, the MSBuild package now depends on an invokable version of Node.js to be present. While machines with newer versions of Visual Studio 2017 (versions 15.8 and above) will not be impacted, some testing\/CI machines, users with Visual Studio 2015, and users of Visual Studio 2017 15.7 and below may need to install <a href=\"https:\/\/nodejs.org\/\" rel=\"nofollow\">Node.js<\/a> directly from the site, through <a href=\"https:\/\/visualstudio.microsoft.com\/downloads\/?utm_medium=microsoft&amp;utm_source=docs.microsoft.com&amp;utm_campaign=button+cta&amp;utm_content=download+vs2017#build-tools-for-visual-studio-2017\" rel=\"nofollow\">Visual Studio 2017 Build Tools<\/a> (<a href=\"https:\/\/docs.microsoft.com\/en-us\/visualstudio\/install\/workload-component-id-vs-build-tools\" rel=\"nofollow\">read more here<\/a>), or <a href=\"https:\/\/www.nuget.org\/packages\/Node.js.redist\/\" rel=\"nofollow\">via a redistribution of Node.js over NuGet<\/a>. Otherwise, upgrading to TypeScript 3.2 might result in a build error like the following:<\/p>\n<div class=\"highlight highlight-text-roff\">\n<pre>The build task could not find node.exe which is required to run the TypeScript compiler. Please install Node and ensure that the system path contains its location.<\/pre>\n<\/div>\n<p>Lastly, TypeScript 3.2 will be the last TypeScript release with editor support for Visual Studio 2015 users. To stay current with TypeScript, we recommend upgrading to Visual Studio 2017 for the latest editing experience.<\/p>\n<h2 id=\"whats-next\">What&#8217;s next<\/h2>\n<p>Our next release of TypeScript is slated for the end of January. Some things we&#8217;ve got planned on the horizon are partial type argument inference and a quick fix to scaffold out declaration files that don&#8217;t exist on DefinitelyTyped. While this list is in flux, you can keep track of our plans on <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/wiki\/Roadmap\">the TypeScript Roadmap<\/a>.<\/p>\n<p>We hope that TypeScript 3.2 makes your day-to-day coding more enjoyable, whether it comes to expressivity, productivity, or ease-of-use. If you&#8217;re enjoying it, drop us a line on Twitter at <a href=\"https:\/\/twitter.com\/typescriptlang\" rel=\"nofollow\">@typescriptlang<\/a>; and if you&#8217;ve got ideas on what we should improve, <a href=\"https:\/\/github.com\/Microsoft\/TypeScript\/issues\/new\/choose\">file an issue on GitHub<\/a>.<\/p>\n<p>Happy hacking!<\/p>\n<p>&#8211; Daniel Rosenwasser and the TypeScript team<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>TypeScript 3.2 is here today!If you&#8217;re unfamiliar with TypeScript, it&#8217;s a language that brings static type-checking to JavaScript so that you can catch issues before you even run your code &#8211; or before you even save your file. It also includes the latest JavaScript features from the ECMAScript standard on older browsers and runtimes by [&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-2107","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"<p>TypeScript 3.2 is here today!If you&#8217;re unfamiliar with TypeScript, it&#8217;s a language that brings static type-checking to JavaScript so that you can catch issues before you even run your code &#8211; or before you even save your file. It also includes the latest JavaScript features from the ECMAScript standard on older browsers and runtimes by [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/2107","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=2107"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/2107\/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=2107"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=2107"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=2107"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}