Skip to content

Instantly share code, notes, and snippets.

@DanielRosenwasser
Last active August 16, 2017 21:26
Show Gist options
  • Save DanielRosenwasser/caa1c02f1c462d78da656bf47ae2dd0c to your computer and use it in GitHub Desktop.
Save DanielRosenwasser/caa1c02f1c462d78da656bf47ae2dd0c to your computer and use it in GitHub Desktop.
Announcing TypeScript 2.5 RC

Announcing TypeScript 2.5 RC

Today we're happy to announce our RC of TypeScript 2.5. To get started with the latest stable version of TypeScript, you can grab it through NuGet, or use the following command with npm:

npm install -g typescript@rc

Visual Studio 2015 users (who have Update 3) can install TypeScript 2.5 RC from here, and Visual Studio 2017 users using version 15.2 or later will be able to get TypeScript by simply installing it from here.

While TypeScript 2.5 will be available for other editors soon, in the meantime you can configure Visual Studio Code and Sublime Text to use a newer version. Other editors may have different approaches to trying TypeScript 2.5 RC out.

Let's dive in and get an overview of what's coming in TypeScript 2.5!

Optional catch binding parameters

There are times when coding where you expect something might fail by throwing an error, but where you might not care what that error is. For example:

let contents;
try {
    contents = fs.readFileSync(".config_file").toString('utf8');
}
catch (unusedError) {
    // File might not exist, just fall back to some defaults.
    contents = createDefaultContents();
}

Notice that unusedError is never referenced in the above example. TypeScript 2.5 introduces a late-stage ECMAScript feature to make the catch binding optional in try/catch statements. That means we can just omit unusedError altogether:

let contents;
try {
    contents = fs.readFileSync(".config_file").toString('utf8');
}
catch {
    // File might not exist, just fall back to some defaults.
    contents = createDefaultContents();
}

Thanks to Tingan Ho for his contribution on this feature!

Deduplicated and redirected packages

When importing using the Node module resolution strategy in TypeScript 2.5, the compiler will now check whether files originate from "identical" packages. If a file originates from a package with a package.json containing the same name and version fields as a previously encountered package, then TypeScript will redirect itself to the top-most package. This helps resolve problems where two packages might 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 --preserveSymlinks compiler flag

TypeScript 2.5 brings the preserveSymlinks flag, which parallels the behavior of the --preserve-symlinks flag in Node.js. This flag also exhibits the opposite behavior 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).

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. For a more concrete example, we'll defer to the documentation on the Node.js website.

What next?

While we'll continue to improve TypeScript before the full 2.5 release, we also have a few other ideas for TypeScript 2.6 that are under way. Some things we'll be working on in the meantime are improvements to TypeScript's --watch mode, and integration with other tools that have file-watching functionality. Our aim is to ensure that as codebases grow larger, TypeScript can give lightning-fast turnaround between the time that you save a file, and the time that you can reload your project. You can keep an eye on our pull request for changes to --watch for the work we've done so far.

Thanks for reading, and we hope you give our release candidate a try!

@rbuckton
Copy link

Should we mention that optional catch binding was a community contribution by tinganho?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment