Today we’re announcing TypeScript 3.2 RC, the release candidate of our next version of TypeScript.<\/p>\n
To get started using the RC, you can get it through NuGet<\/a>, or use npm with the following command:<\/p>\n You can also get editor support for TypeScript 3.2 by:<\/p>\n We have some important information below for NuGet users and Visual Studio 2015 users<\/a>, so please continue reading if you use either product.<\/p>\n Let’s look at some of what’s coming in TypeScript 3.2!<\/p>\n As you might’ve guessed from the title of this section, TypeScript 3.2 introduces stricter checking for Well in JavaScript, Unfortunately, in its earlier days, TypeScript lacked the power to model these functions, and 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 Combined, the two of of them can ensure our uses of As an example, we can look at how Needless to say, whether you do any sophisticated metaprogramming, or you use simple patterns like binding methods in your class instances ( JavaScript supports a handy way of copying existing properties from an existing object into a new one called “spreads”. To spread an existing object into a new object, you define an element with three consecutive periods ( TypeScript 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.<\/p>\n This was an error because we had no way to express the return type of We could have come up with a new concept in the type system called an “object spread type”, and in fact we had a proposal for exactly that<\/a>. Essentially this would be a new type operator that looks like 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 Given that intersections model the common cases, and that they’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 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 lacks<\/em> some specified properties.<\/p>\n In the above, the most intuitive way to look at this code is that Here we also considered a new rest operator, but we saw we already had the facilities for describing the above: our If we want to consider the properties of While it’s not the most beautiful type (hey, I’m no George Clooney myself), we can wrap it in a helper type like 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 BigInt support in TypeScript introduces a new primitive type called the While you might imagine close interaction between As specified in ECMAScript, mixing Also important to note is that We’d like to extend a huge thanks to Caleb Sander<\/a> for all the work on this feature. We’re grateful for the contribution, and we’re sure our users are too!<\/p>\n As we mentioned, BigInt support is only available for the For that reason, we have no immediate plans to provide downleveling support. On the bright side, Node.js 11 and newer versions of Chrome already support this feature, so you’ll be able to use BigInts there when targeting Certain targets may include a polyfill or BigInt-like runtime object. For those purposes you may want to add 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 per se<\/em>, but upgraders should note take note of any issues they encounter and report them<\/a>.<\/p>\n Certain parameters no longer accept Certain properties that are WebKit-specific have been deprecated. They are likely to be removed in a new version.<\/p>\n As a solution, you can use We have some changes coming in TypeScript 3.2 for NuGet and VS2015 users.<\/p>\n 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 a globally 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, testing\/CI machines, users with Visual Studio 2015, and users of Visual Studio 2017 15.7 and below will need to install Node.js<\/a> and will likely see a message like the following:<\/p>\n 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>\nnpm install -g typescript@rc<\/pre>\n
\n
strictBindCallApply<\/code><\/h2>\nbind<\/code>, call<\/code>, and apply<\/code>. But what does that mean?<\/p>\nbind<\/code>, call<\/code>, and apply<\/code> are methods on functions that allow us to do things like bind this<\/code> and partially apply arguments, call functions with a different value for this<\/code>, and call functions with an array for their arguments.<\/p>\nbind<\/code>, call<\/code>, and apply<\/code> were all typed to take any number of arguments and returned any<\/code>. Additionally, ES2015’s arrow functions and rest\/spread arguments gave us a new syntax that made it easier to express what some of these methods do – and in a more efficient way as well.<\/p>\nbind<\/code>, call<\/code>, and apply<\/code> without any hard-coding:<\/p>\n\n
this<\/code> parameter types<\/a> from TypeScript 2.0<\/li>\nbind<\/code>, call<\/code>, and apply<\/code> are more strictly checked when we use a new flag called strictBindCallApply<\/code>. When using this new flag, the methods on callable objects are described by a new global type called CallableFunction<\/code> which declares stricter versions of the signatures for bind<\/code>, call<\/code>, and apply<\/code>. Similarly, any methods on constructable (but not callable) objects are described by a new global type called NewableFunction<\/code>.<\/p>\nFunction.prototype.apply<\/code> acts under this behavior:<\/p>\nfunction 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>\nthis.foo = this.foo.bind(this)<\/code>), this feature can help catch a lot of bugs. For more details, you can check out the original pull request here<\/a>.<\/p>\nObject spread on generic types<\/h2>\n
...<\/code>) like so:<\/p>\nlet 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\" };<\/pre>\n<\/div>\nfunction merge<T, U>(x: T, y: U) {\r\n \/\/ Previously an error!\r\n return { ...x, ...y };\r\n}<\/pre>\n<\/div>\nmerge<\/code>. There was no syntax (nor semantics) that could express two unknown types being spread into a new one.<\/p>\n{ ...T, ...U }<\/code> to reflect the syntax of an object spread.\nWhen both T<\/code> and U<\/code> are known, that type would flatten down to some new object type.<\/p>\n\n
Foo & Bar<\/code>).<\/li>\nObject.assign<\/code> – a function that exhibits most of the behavior of spreading objects – is already modeled using intersection types, and we’ve seen very little negative feedback around that.<\/li>\n<\/ol>\n\/\/ Returns 'T & U'\r\nfunction merge<T, U>(x: T, y: U) {\r\n return { ...x, ...y };\r\n}\r\n\r\n\/\/ Returns '{ name: string, age: number, greeting: string } & T'\r\nfunction foo<T>(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<\/div>\nObject rest on generic types<\/h2>\n
let { x, y, z, ...rest } = obj;<\/pre>\n<\/div>\nrest<\/code> copies over all the properties from obj<\/code> apart<\/em> from x<\/code>, y<\/code>, and z<\/code>. For the same reason as above, because we didn’t have a good way to describe the type of rest<\/code> when obj<\/code> is generic, we didn’t support this for a while.<\/p>\nPick<\/code> and Exclude<\/code> helper types in lib.d.ts<\/code>. To reiterate, ...rest<\/code> basically picks off all of the properties on obj<\/code> except for x<\/code>, y<\/code>, and z<\/code> in the following example:<\/p>\ninterface XYZ { x: any; y: any; z: any; }\r\n\r\nfunction dropXYZ<T extends XYZ>(obj: T) {\r\n let { x, y, z, ...rest } = obj;\r\n return rest;\r\n}<\/pre>\n<\/div>\nT<\/code> (i.e. keyof T<\/code>) except for x<\/code>, y<\/code>, and z<\/code>, we can write Exclude<keyof T, \"x\" | \"y\" | \"z\"><\/code>. We then want to pick those properties back off of the original type T<\/code>, which gives us<\/p>\nPick<T, Exclude<keyof T, \"x\" | \"y\" | \"z\">>`.<\/pre>\n
DropXYZ<\/code>:<\/p>\ninterface XYZ { x: any; y: any; z: any; }\r\n\r\ntype DropXYZ<T> = Pick<T, Exclude<keyof T, keyof XYZ>>;\r\n\r\nfunction dropXYZ<T extends XYZ>(obj: T): DropXYZ<T> {\r\n let { x, y, z, ...rest } = obj;\r\n return rest;\r\n}<\/pre>\n<\/div>\nBigInt Support<\/h2>\n
esnext<\/code>.<\/p>\nbigint<\/code> (all lowercase). You can get a bigint<\/code> by calling the BigInt()<\/code> function or by writing out a BigInt literal by adding an n<\/code> to the end of any integer numeric literal:<\/p>\nlet 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 are *so* big!\r\nfunction fibonacci(n: bigint) {\r\n let result = 1n;\r\n for (let last = 0n, i = 0n; i < 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<\/div>\nnumber<\/code> and bigint<\/code>, the two are separate domains.<\/p>\ndeclare 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'.<\/pre>\n<\/div>\n
number<\/code>s and bigint<\/code>s in arithmetic operations is an error. You’ll have to explicitly convert values to BigInt<\/code>s.<\/p>\nconsole.log(3.141592 * 10000n); \/\/ error\r\nconsole.log(3145 * 10n); \/\/ error\r\nconsole.log(BigInt(3145) * 10n); \/\/ okay!<\/pre>\n<\/div>\n
bigint<\/code>s produce a new string when using the typeof<\/code> operator: the string \"bigint\"<\/code>. Thus, TypeScript correctly narrows using typeof<\/code> as you’d expect.<\/p>\nfunction 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<\/div>\nCaveats<\/h3>\n
esnext<\/code> target. It may not be obvious, but because BigInts have different behavior for mathematical operators like +<\/code>, -<\/code>, *<\/code>, etc., providing functionality for older targets where the feature doesn’t exist (like 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>\nesnext<\/code>.<\/p>\nesnext.bigint<\/code> to the lib<\/code> setting in your compiler options.<\/p>\nBreaking changes and deprecations<\/h2>\n
JSX resolution changes<\/h3>\n
lib.d.ts<\/code> changes<\/h3>\nMore specific types<\/h4>\n
null<\/code>, or now accept more specific types as per the corresponding specifications that describe the DOM.<\/p>\nMore platform-specific deprecations<\/h4>\n
wheelDelta<\/code> and friends have been removed.<\/h4>\nwheelDeltaX<\/code>, wheelDelta<\/code>, and wheelDeltaZ<\/code> have all been removed as they are deprecated properties on WheelEvent<\/code>s.<\/p>\ndeltaX<\/code>, deltaY<\/code>, and deltaZ<\/code> instead. If older runtimes are a concern, you can include a file called legacy.d.ts<\/code> in your project and write the following in it:<\/p>\n\/\/ 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<\/div>\nA note for NuGet and Visual Studio 2015<\/h2>\n
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.\r\n<\/code><\/pre>\nWhat’s next<\/h2>\n