|TypeScript 2.5 Adds Optional Catch Binding|
|Written by Kay Ewbank|
|Monday, 21 August 2017|
The release candidate of TypeScript 2.5 is available, though just for Visual Studio and Sublime Text at the moment. Support for other editors will be added soon.
While work will continue on TypeScript 2.5, other changes such as a watch mode, and integration with other tools that have file-watching functionality, will be kept for TypeScript 2.6.
The improvements to the release candidate start with support for optional catch binding parameters. According to the TypeScript developers, this is for use on those occasions where you expect something might fail by throwing an error, but you don't particularly care what that error is. TypeScript 2.5 introduces a late-stage ECMAScript feature to make the catch binding optional in try/catch statements
The second main improvement is better handling of deduplicated and redirected packages. If you import files using the Node module resolution strategy, the compiler will now check whether they come from “identical” packages. If you import a file from a package with a package.json containing the same name and version fields as one that TypeScript has already encountered, it will redirect itself to the top-most package. This helps avoid problems where two packages contain identical declarations of classes, but which contain private members that cause them to be structurally incompatible. It also reduces the memory and runtime footprint of the compiler and language service.
The final main change to this version is the addition of the preserveSymlinks flag. This behaves similarly to the --preserve-symlinks flag in Node.js. The new flag also behaves in the opposite way to Webpack’s resolve.symlinks option (i.e. setting TypeScript’s preserveSymlinks to true parallels setting Webpack’s resolve.symlinks to false, and vice-versa).
According to the TypeScript developers:
"in this mode, references to modules and packages (e.g. imports and /// <reference type="..." /> directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to."
The release candidate is available through NuGet.
or email your comment to: firstname.lastname@example.org
|Last Updated ( Monday, 21 August 2017 )|