Windows 10: Announcing TypeScript 2.5

We might want to declare a variable namedxyzwhose type is tied to to the type ofbar. The correct way to write this would be using an indexed access type:
Code: // Get the type of the property named 'bar' off of 'Foo'. var xyz: Foo["bar"][/quote]
but we might accidentally writevar xyz: Foo.bar. TypeScript now can now suggest the correct one in many cases.





JSDoc type assertion support in JavaScript files

In TypeScript 2.4, we introduced the ability to get type-checking in JavaScript files so that users can more easily migrate to TypeScript, and have an easier experience with certain more lightweight projects. Taking advantage of this is as simple as adding a// @ts-checkat the top of your.jsfile, or turning on thecheckJsflag in youttsconfig.json‘scompilerOptions.

One thing that it lacked was the ability to “cast” or “assert” the type of an expression. This is important for situations where you know a little more than the type-checker and need to tell it so. To come up with a trivial example, let’s take the following JavaScript code:
Code: // @ts-check var foo = Math.random() ? "hello" : 100; foo.toUpperCase(); // ~~~~~~~~~~~ // Error! Property 'toUpperCase' does not exist on type 'string | number'.[/quote]
TypeScript correctly indicates that we might be calling a method that doesn’t exist onnumbers. If we wanted to get around this so we can easily get our runtime error, we could write a JSDoc type assertion:
Code: // Works! var bar = /** @type {string} */ (foo); bar.toUpperCase();[/quote]
The syntax is/** @type {YOUR_TYPE_HERE} */ (someParenthesizedExpression).

Keep in mind that if you’ve enabled JavaScript checking on a file, invalid type assertions will still get caught:
Code: var clearlyNumber = /** @type {string} */ (100); // ~~~~~~~~~~~~~~ // Error! Type 'number' cannot be converted to type 'string'.[/quote]
Optionalcatchclauses

Thanks to work byTingan Ho, TypeScript 2.5 brings a new ECMAScript-bound feature for making catch clauses optional. Much of the time, you’ll find yourself writing atry/catchbut not really caring about the thrown error. For example:
Code: [let contents; try { contents = fs.readFileSync(".config_file").toString('utf8'); } catch (unusedError) { // File might not exist, just fall back to some defaults. contents = createDefaultContents(); }[/quote]
Notice thatunusedErroris never referenced in the above example. Barring philosophical issues about whether it’s appropriate to ignore the error, we can make our code a little cleaner by taking advantage of the fact that thecatchvariable is now optional.
Code: let contents; try { contents = fs.readFileSync(".config_file").toString('utf8'); } catch { // File might not exist, just fall back to some defaults. contents = createDefaultContents(); }[/quote]
Deduplicated and redirected packages

When importing using theNodemodule 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 apackage.jsoncontaining the samenameandversionfields 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 containprivatemembers that cause them to be structurally incompatible.

As a nice bonus, this can also reduce the memory and runtime footprint of the compiler and language service by avoiding loading.d.tsfiles from duplicate packages.

The --preserveSymlinks compiler flag

TypeScript 2.5 brings thepreserveSymlinksflag, which parallels the behavior ofthe--preserve-symlinksflag in Node.js. This flag also exhibits the opposite behavior to Webpack’sresolve.symlinksoption (i.e. setting TypeScript’spreserveSymlinkstotrueparallels setting Webpack’sresolve.symlinkstofalse, 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 tothe documentation on the Node.js website.

Enjoy!

We hope our work in TypeScript 2.5 will make you happier and more productive. If it did, let us know on Twitter with the#iHeartTypeScripthashtag.

Out team appreciates any sort of feedback on how we can improve. Feel free to let us know about any issues you run into or helpful ideas you think might make TypeScript even better to useon our GitHub issue tracker.

As for what’s next, we’ve caught most of what’s new on this blog post, but you can always check out ourwhat’s new in TypeScriptpage on our wiki for some more details, and keep an eye onour Roadmapthat highlights our current plans and is frequently updated.

Thanks for reading and happy hacking!

[/quote]
Source: Announcing TypeScript 2.5 | TypeScript

:)

 

Windows Explorer crashing

I tried removing the Windows Security Update and after a reboot, problem still occurs when file explorer sees a typescript file. File explorer crashes.

 

munich public transport on Google Maps

yesterday munich announced the public transport plan and time table and routing to be available on google.



my message about it was accompanied by a german screenshot - and because of the the german part it was deleted from the board.







As PT 2.5 is available in betalabs i thought it will be have full support for munich public transport.





does anyone know wether or when this will come to symbian?