
TypeScript 2.3 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2017/04/27/announcing-typescript-2-3/
======
octref
Author of vetur[0] here, glad to see it getting featured :-)

Started this plugin last October to provide better editor support for Vue
single file component, now vetur has support for embedded IntelliSense /
error-checking / syntax-highlighting / emmet / snippet / linting / formatting.
By embedded support I mean each feature is available for at least html/css/js,
some features are also available for scss/less/ts/etc.

@sandersn from TS team has been really helpful in helping me integrating TS's
Language Server to powers the advanced IntelliSense in vetur. As vue / vuex /
vue-router now comes with type definitions, you get awesome auto completion
such as [1] and [2].

Now that IntelliSense in js/ts sections is almost complete, vetur's next step
is to use TS's Language Server to extract info from Vue SFC's script part to
power IntelliSense in templates, such as prompting a list of `props` for
`v-if`, and prompting a list of `methods` for `@click`.

Give it a try and let me know any bugs or features you want to see!

[0]: [https://github.com/octref/vetur](https://github.com/octref/vetur) [1]:
[https://twitter.com/octref/status/854812632142024705](https://twitter.com/octref/status/854812632142024705)
[2]:
[https://twitter.com/octref/status/857350977581723648](https://twitter.com/octref/status/857350977581723648)

~~~
ronjouch
Vetur is awesome! Thanks octref for your continued work and support :)

The "feature" I'd like to see most is a "perfect setup" guide (or maybe auto-
detecting-and-helping logic?) detailing what's required to get all the
features working. Currently for example I don't get HTML/CSS formatting, even
though it was featured in 0.6.0 changelog, but I have no idea why :-/ . Got
this feeling a few times with vetur as well as other linters: things work, but
maybe not 100%, and it can be opaque to dig deeper: is it due to vscode
misconfiguration? vetur misconfiguration? missing tooling? I don't know.

EDIT: these TS-dependent auto-completions look fantastic. I'm planning to
migrate my current Vue project to TS, but for now it's just JS. Do you have
any recommendation for Vue2-with-TypeScript documentation? Or, even better, a
JS-to-TS Vue2 migration guide?

~~~
crooked-v
To go with this, I would be incredibly happy just to find a complete guide for
Webpack + Babel + TS + Vue. The last time I tried I could never quite get
anything put together all the way.

~~~
xenreal
I used already configured template for such setup:
[https://github.com/AbeHaruhiko/vue-webpack-
typescript](https://github.com/AbeHaruhiko/vue-webpack-typescript)

------
msoad
TypeScript opening up plugin APIs is going to lead to a massive number of
interesting project. I'm tracking a few of them that are done before 2.3 was
out. Very interesting stuff:

* TypeScript CSS Modules plugin [1]. It allows you to type check CSS classes etc.

* TypeScript Vue plugin [2]. Type check .vue files. Competing with the one mentioned in the article

* TypeScript GraphQL plugin [3]. Type check GraphQL queries

I desperately need TypeScript React Hot Module Replacement Plugin. If someone
is working on it please let me know!

[1] [https://github.com/HerringtonDarkholme/ts-css-
plugin](https://github.com/HerringtonDarkholme/ts-css-plugin)

[2] [https://github.com/sandersn/vue-ts-
plugin](https://github.com/sandersn/vue-ts-plugin)

[3] [https://github.com/Quramy/ts-graphql-
plugin](https://github.com/Quramy/ts-graphql-plugin)

~~~
xpaulbettsx
> I desperately need TypeScript React Hot Module Replacement Plugin

I worked on this for electron-compile but unfortunately React HMR itself
(react-proxy) fails with actual classes (i.e. using the `class` keyword not-
transpiled) or anything other than Babel's ES5 class keyword transpiler. Once
they fix that, apps created via electron-forge or that use electron-compile
will get TypeScript HMR automatically.

------
anonyfox
Since 2.1 ts is becoming a de-facto default choice for any serious JS projects
I'd say. In conjunction with VSCode it really shines and makes JS sometimes
even enjoyable...

But there is an issue that quirks our team almost daily: the bolted-on
typesystem provides a false sense of safety. You can look at an API response,
write an interface for the data structure, build functionality ontop of it,
and when the API response structure changes in subtle ways over time,
everything _may_ break without notice. There is no way to enforce an interface
through casting anywhere, not even via some code generation or sth like that.

~~~
Nemo157
Use something like
[https://github.com/lbovet/typson](https://github.com/lbovet/typson) to
generate a JSON schema for your interfaces, then use a JSON schema validator
before casting the API response to your interface.

I haven't touched TS since ~1.3, but this was all working well back then at
least.

~~~
sceutre
Typson hasn't been updated for a while, we use
[https://github.com/YousefED/typescript-json-
schema](https://github.com/YousefED/typescript-json-schema) which works with
recent typescript coupled with [https://github.com/mafintosh/is-my-json-
valid](https://github.com/mafintosh/is-my-json-valid)

------
macrael
I'd love a pro con from someone who's really tried out both TypeScript and
Flow. I tried to get either of them started last weekend and couldn't get to a
good place. Flow was missing annotations for three.js and typescript didn't
seem to support es6isms. I found a compiler for the typescript definitions
file for threejs but also couldn't sort out how to actually import that into
flow.

~~~
andreypopp
Ok, I've used TS while contributing to OSS written with TS and I've used Flow
extensively in production settings.

The main takeaway for me is that TS is much much less sound than Flow. That
means it checks less invariants which in turn makes you less trust it...

Consider the following code which is valid (!) in TS:

    
    
        let promisedString: Promise<string> = new Promise(
          resolve => {
            // Perfectly valid in TypeScript!
            resolve(42)
          }
        )
    

Another downside of TS is poor type inference. It requires to annotate each
top level function while Flow only requires to annotate exported functions.

Even the following simple piece of code will make TS ask you to annotate
doAddition function:

    
    
        export function addition(a: number, b: number) {
          return doAddition(a, b)
        }
    
        function doAddition(a, b) {
          return a + b
        }
    

I'm really glad Flow doesn't force me into it.

Edit: spelling

~~~
bcherny
For your 1st example, it's failing because by explicitly annotating
`promisedString` you are widening the type from the inferred `number` to
`any`. If you remove the explicit annotation and let TS do its job, the code
will fail (as expected) :).

For your second example - it's a divisive issue. I believe that a Hindley-
Milner style type resolver (what Flow uses) is more usable, but there is a
strong argument against it too [0].

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

~~~
andreypopp
> by explicitly annotating `promisedString` you are widening the type from the
> inferred `number` to `any`

That's something I don't understand. Isn't that incorrect behaviour? Shouldn't
TS try unify RHS and LHS?

~~~
WorldMaker
TS is trying to unify RHS and LHS. TS follows a somewhat complicated widening
process to unify unannotated generics, somewhat leaning towards ease of use
over strictness. Adding additional strictness checks like noImplicitAny can
help catch these situation. (In this case, it doesn't help, because the
resolve argument is inferred `resolve: (value: any) => void` rather than
`resolve: any` which would give a clear implicit any error. Inferred any in
generic callbacks sound like a good strictness test to add...)

In this case in Typescript it is generally more strict to add a type
annotation to the generic than the LHS:

    
    
      let promise = new Promise<string>((resolve) => resolve(42)) // This won't work
    

This is as much because the inference here that matters isn't between LHS and
RHS but between generic arguments and function return inference.

------
rattray
Highlights / tl;dr:

\- ability to check .js files

\- default type parameters (eg; `class Component<Props, State = object> {}`)

\- generators/iterators (including async-generators, a stage 3 proposal).

\- `--strict` flag to easily give you --strictNullChecks, --noImplicitAny,
--noImplicitThis, and --alwaysStrict

\- language server plugins are official (the Angular and Vue ones were
promoted in particular)

~~~
sheetjs
I wish TS would consider the annotation-in-comments form from flow:
[https://flow.org/blog/2015/02/20/Flow-
Comments/](https://flow.org/blog/2015/02/20/Flow-Comments/)

For switching a large existing JS codebase, it's easy to add flow comments
without changing the final minified builds, allowing you to reap the full
benefits of the type check.

~~~
mohamedhegazy
TypeScript allows for JSDoc Comments for types in .js files with `--allowJs`.
you do not need to change your code for that.

See [https://github.com/Microsoft/TypeScript/wiki/JSDoc-
support-i...](https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-
JavaScript)

~~~
yathern
Thank you! I've been trying to figure out how to get JSDoc-ed code to get
appropriately typed in Visual Studio Code with Typescript files as well.

------
skrebbel
Now that typescript can compile generators down to ES5 and ES3, you could
reasonably replace Babel by tsc entirely, right? I mean, with its --allowJs
flag it's really just a javascript transpiler. Async/await, generators, JSX,
array/object spread, destructuring.. it's all in there.

Did anyone try this? We're doing a hybrid babel/ts app and it wouldn't hurt
ditching one of the two tools.

~~~
kervin
You still need to provide some polyfills

~~~
WorldMaker
That might be a great idea for a plugin: add warnings/errors and automatic
code fixes to import core-js (or similar) polyfills based on code usage.

------
fahrradflucht
My personal Gem in this release: Generic parameter defaults. [0] This makes
altering a generic interface or a generic type alias in a non-breaking way
much easier which is very powerfull in a large code base.

[0]: [https://github.com/Microsoft/TypeScript/wiki/What's-new-
in-T...](https://github.com/Microsoft/TypeScript/wiki/What's-new-in-
TypeScript#generic-parameter-defaults)

------
chamakits
This is fantastic!

Allowing type checking on js files with comments will allow me to start
improving our exciting hard to maintain large code base. I attempted to do
this with flow as well before, and it did the job well enough (although at the
beginning I ran into a number of issues), but I have a preference for
TypeScript, and the next time I work on that project I will likely be doing
heavy usage of this.

~~~
mattbierner
With VSCode 1.12 (aka the current insiders build) you can also enable
JavaScript type checking without creating a jsconfig.json or even changing
your source code by setting "javascript.implicitProjectConfig.checkJs":true in
your workspace or user settings. This setting applies to any JavaScript file
that is not part of a jsconfig or tsconfig project. Besides catching errors,
checkJs also enables a number of quick fixes in JavaScript files.

Please let us know if you see any errors while trying out new TypeScript 2.3
features in VSCode or have any thoughts on how our JS/TS support could be
improved:
[https://github.com/Microsoft/vscode/issues/new](https://github.com/Microsoft/vscode/issues/new)

------
styfle
The language service API is huge! One of the main reasons I even bothered to
learn React was because TypeScript supported type checking JSX.

Back when I picked up TS, I was using Handlebars for templating. The templates
were the only part of the code that didn't type check which was really
annoying when doing something like "Refactor all references". I tried to write
my own templating[0] and realized I was basically reinventing JSX, so I wrote
a react boilerplate[1].

The language service is going to make Vue, Angular, Svelt, and any other
template syntax way more attractive.

[0]: [https://github.com/styfle/typed-tmpl](https://github.com/styfle/typed-
tmpl)

[1]: [https://github.com/styfle/react-server-example-
tsx](https://github.com/styfle/react-server-example-tsx)

------
simplify
The GraphQL plugin[1] looks great. I was eagerly waiting for Flow's tooling to
catch up because of their GraphQL support, but I guess TypeScript is running
laps :)

[1] [https://github.com/Quramy/ts-graphql-
plugin](https://github.com/Quramy/ts-graphql-plugin)

------
snugbug
I hope TS adds native Swift-style optional values and chaining, where it fails
at compile time if you try to access an optional without unwrapping it first.
Conversely non-optional values _cannot_ be null!

There are projects that add optional functionality
([https://www.npmjs.com/package/ts-optional](https://www.npmjs.com/package/ts-
optional)), but I don't see how it prevents you from setting regular values to
null.

~~~
zip1234
What do you mean by "Swift-style"? TypeScript allows you to declare optional
values on an object:

interface Test{

number? myOptionalNumber;

}

Is that what you mean?

~~~
snugbug
It is. I guess then you have to use the --strictNullChecks compiler flag to
get the rest of the benefits

------
Too
Not sure if this "type checking with comments" is a good thing or not. On one
hand it might convert some hesitant users, on the other hand it will cause
some code bases to stay like half assed js-with-comment-annotations forever
instead of being converted to proper typescript once and for all.

It will also require extreme discipline, like a CI build machine checking each
commit, because the comments allow clueless people to edit the code like plain
JS and not get any compilation errors, later when the next person comes and
edits it with a typescript compiler they will get a broken build. If everybody
works under the same circumstances, i.e always typescript, this is less likely
to happen

------
bsimpson
I wonder if the plugin system will evolve into an AST-transform ecosystem like
Babel's.

~~~
Touche
I hope not. Didn't we already learn this lesson from macros? Having code that
appears to do one thing but actually does something very different is a
maintenance nightmare. Once the people who decided to add that AST transform
plugin are gone and new people take over that don't know about it, the trouble
really starts.

Again, we've seen this in languages with macros. At least with macros it's
part of main codebase; you usually have to include them in some way. With
these AST transform systems the secret is tucked away in a build script
somewhere.

~~~
bpicolo
I've had poor experiences with PostCSS w/ regards to AST transforms. The
different plugins tend to not interact with each other at all because they're
just transforms. Feels worse than something that works together all around
like scss.

------
homulilly
for all the problems I have with Microsoft and some of their other products, I
really have to say that the typescript and vscode teams are doing a phenomenal
job. Every release is a vast improvement over an already great set of tools.
don't think I've been as excited to see new release announcements since the
early days of Firefox.

------
tabeth
Was @ts-check just added in this version? I assume so, but if not -- is it
possible to use TypeScript and just @ts-check and get basically the full type-
checking power (assuming the items to be checked follow the standard lib)?

~~~
mohamedhegazy
you could. jsut add `@ts-check` in your .js file, open it in VSCode, or pass
it to the `tsc --allowjs a.js` on the commandline.

------
alistproducer2
>Previously, TypeScript didn’t support compiling generators or working with
iterators.

I had no idea. That seems like a big deal, no?

~~~
scanr
It didn't support transpiling generators to es5. Compiling to es6 would work
and you could add babel to transpile down to es5 so in practice this wasn't
much of a problem.

Async iterators are very exciting and builds should be faster without babel in
the pipeline.

------
mosen
I just upgraded our version to TS 2.3, removed Babel (which we were using for
generator support), and it cut our build time in half.

------
dkarapetyan
Anders and team are like programmer whisperers. Every design decision has been
a productivity boon.

~~~
nojvek
Well they listen to their users and community. Their PMs do a fantastic job at
outreach, listening and prototyping things that would make life easier for
developers.

------
mullsork
If only the Flow team was half as active as TS. Is there even any reason to
use Flow long term or are they eventually going to tell their users to either
switch to TS or that ML thing of theirs?

------
nojvek
The checkJS option is awesome. I believe a ton of opensource JS projects on
the web can benefit from this. Unlike flow which is written in a different
language and has little tooling, typescript can now just act as a type
checker, with vscode offer great intellisense and generally play very well
with existing build tools.

This is just fucking awesome. I see Types as a way of documenting your code
for the other team members who will use your API.

------
myth_drannon
added type checking for JS files // @ts-check in similar fashion to //@flow
Trying to eat up market share from Flow

~~~
wildpeaks
It's a good thing, competition is a fuel of innovation :)

~~~
myth_drannon
Yes, especially between two large corporations. If Flow was created entirely
by open-source enthusiasts I would be worried for the project. Since it's FB
vs MS, well let them bring the best of their minds.

------
xellisx
TypeScript, a higher level version of something that is super high level in
the first place. So it's converting from one scripting language to another,
not straight down to byte code. So you are developing a sitcom for the
Northern American market, but decide to write it in Mexican Spanish, to be
translated to American English. Great! It has the same issues as ORMs.
Javascript isn't that hard. As for ORMs - How many database changes are you
planing on doing? ORMs seam nice for simple stuff, but still ended up slowing
stuff down just on the simple stuff (See translating to Mexican Spanish to
American English). Start doing complex stuff like joins and join with extra
information, then it's just that much overhead.

If you can't do JavaScript, find someone that can. Can't do query in which
ever database, find someone skilled in said database. Can't do CSS... Can't do
HTML, GTFO of the business.

~~~
mbleigh
TypeScript isn't higher level than JavaScript. It _is_ JavaScript, just with a
lightweight type system. It doesn't make things "easier" than JS, it makes the
process of building large JS apps less error-prone.

------
eberkund
I'm curious, what frameworks are people using TypeScript with? Is it mostly
Angular or are people using it with others also?

~~~
WorldMaker
I've been using Typescript for a while and have used a lot of frameworks for
it, and some lack of frameworks (one of my earliest Typescript projects was a
large conversion of an enterprise JS code base consisting of a mixture of
JQuery 1.x, Backbone, and Knockout code). These days I've got one big project
in Aurelia (which I'm not entirely thrilled with sometimes) and another in
Cycle.js (which is quite cool and I'm using TSX there even).

------
saosebastiao
Would the plugin system allow for things like conditional compilation or
closure-like optimizations?

~~~
orta
No, to my knowledge the plugin system won't allow extending the compiler's
knowledge of _new_ symbols inside a source file

------
skocznymroczny
I've been using Dart for a few months. What advantages does TypeScript have?

------
INTPenis
I know MS has really changed lately and even I have taken to using their
Visual Studio Code editor instead of vim. But it's kinda funny that the first
link I click in this blog post is 404. :) Classic MS.

