
Announcing TypeScript 2.6 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2017/10/31/announcing-typescript-2-6/
======
dandare
I am not coding daily anymore and I am a bit worried that I am losing touch
with all the TypeScript improvements. I never imagined that one day I will
complain the web programming language is evolving too fast :)

~~~
DanRosenwasser
Luckily we try to have a regular release cadence (~2 months or so), and you
can set your expectations with the Roadmap[1]. Hope you enjoy the release!

[1]
[https://github.com/Microsoft/TypeScript/wiki/Roadmap](https://github.com/Microsoft/TypeScript/wiki/Roadmap)

~~~
dandare
You guys are doing a stellar job!

The only additional thing I could wish for is a learning-oriented portal with
a multitude of examples, focused on people with traditional JS background,
that wish to learn all the advanced (coming from advanced languages) coding
concepts.

------
fold_left
I've recently started using TypeScript and VS Code properly and have really
enjoyed it. The only niggle I've had so far has been around typing curryable
functions, but I appreciate that's probably a tricky thing to cater for nicely
(?)

~~~
zenojevski
There's a proposal in the roadmap to deal with this:

[https://github.com/Microsoft/TypeScript/issues/5453](https://github.com/Microsoft/TypeScript/issues/5453)

------
wildpeaks
I wish there existed a lib for code that targets both Node and the browser,
something like Eslint's _" shared-node-browser"_ env.

~~~
nailer
browserify is the node standard API in the browser.

~~~
wildpeaks
Yes I know what Browserify (and Webpack, Require.js, Rollup, JSPM, etc..) are,
I've used them extensively and even wrote extensions for them :)

What I was referring to is the the "lib" setting of tsconfig.json: when you
have code that is meant for both Node and the web, it would be better tested
only against the smaller scope of functions and globals that are shared by
both (like the eslint env "shared-node-browser").

Right now, people add the "dom" lib even when they just meant the non-DOM
subset common to both (such as console), so if for example you accidentally
refer to a window method in a module meant to be usable in both contexts, it
won't get caught until runtime.

