12 ms·

TypeScript 2.3

366 points by DanRosenwasser 9y ago

bsimpson 9y ago
I wonder if the plugin system will evolve into an AST-transform ecosystem like Babel's.
- DanRosenwasser 9y ago
  There's already a way to consume TypeScript through its API and inject a custom transform today, so a lot of the machinery is already in place.
- Touche 9y ago
  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 9y ago
    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.
  - 15155 9y ago
    Much of this, IMO, is due to a lack of a type system. The maintenance nightmare comes from when behavior changes and you have no way of knowing about it - a type system staves off some of this.
- rattray 9y ago
  I hope so – so far it looks a lot less powerful. One aspect that's disappointing to me is that the AST they use seems fairly idiosyncratic; Babel's is quite close to the ESTree spec, and even easier to work with. Relatedly, it also doesn't look possible to swap out the parser, which Babel makes easy. I'd love to use the TS typechecker for a compile-to-js lang I'm working on ([0]), but would need to use my own parser. [0] http://lightscript.org http://lightscript.org
  - DanRosenwasser 9y ago
    Hi Alex (I have an email from you that I have to respond to)! TS guy here. We've had discussions around this and the reason we use our own AST format is for compilation speed and editing scenarios, both of which our team really focuses on. I'll also note that incredible folks like James Henry have already written tools to convert TypeScript ASTs to the ESTree format[1]. I've heard it's been working well for using ESLint on TypeScript code. [1]: https://github.com/eslint/typescript-eslint-parser https://github.com/eslint/typescript-eslint-parser
    - rattray 9y ago
      Hey Dan! Yeah, prettier has also been working hard[0] towards TS support, frequently referencing typescript-eslint-parser (I haven't been involved). Personally I want to go the other way – ESTree to TS – so while the prior art is helpful, very little of the code could be reused. If TypeScript (or a fork thereof) exposed an option to use your own parser, an ESTree -> "TSTree" library could be used to map the output of any babel plugin to TypeScript. I'm sure you've discussed/considered this; presumably speed is a top concern. [0] https://github.com/prettier/prettier/issues/13 https://github.com/prettier/prettier/issues/13 and https://github.com/prettier/prettier/issues/1306 https://github.com/prettier/prettier/issues/1306
rattray 9y ago
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)
- deleted 9y ago
  [deleted]
- sheetjs 9y ago
  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 9y ago
    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-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...
    - yathern 9y ago
      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.
myth_drannon 9y ago
added type checking for JS files // @ts-check in similar fashion to //@flow Trying to eat up market share from Flow
- wildpeaks 9y ago
  It's a good thing, competition is a fuel of innovation :)
  - myth_drannon 9y ago
    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.
chamakits 9y ago
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.
- martijndeh 9y ago
  I agree. Additionally, it looks like the comments feature is compatible with the JSDoc syntax. I'm not too sure about the return syntax though. This means I can start type checking some of the large and older JavaScript projects, all documented with JSDoc, of some of my clients. I'm eager to test this out. In my experience, in some organisations, it's hard to introduce TypeScript instead of JavaScript, because of reasons. For example, one of my clients made a bet on CoffeeScript back in the days, and that didn't work out, so now they are hesitant to adopt anything. Being able to introduce at least the type checking feature will start to drive change to this hesitation.
- mattbierner 9y ago
  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
macrael 9y ago
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.
- msoad 9y ago
  We did a very deep dive in comparison between the two before going with TypeScript. The biggest differences are: 1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions 2. Tooling, TypeScript has a much better tooling support 3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular. Syntax and personal opinions was not part of our decision making process.
  - nojvek 9y ago
    with the checkJs option, now you don't even need to rename your files to .ts, You can just use typescript as a nice typechecker and give you sane .js
- freditup 9y ago
  What es6 features were you looking for that TS didn't support? In general, it supports most stage 3 and higher ES proposals. (Note that TS doesn't polyfill methods; it only adds support for syntactic elements)
- styfle 9y ago
  I suspect you didn't set target to ES6 in the `tsconfig.json` file which would limit some of the features. If you don't specify, I think the default is ES5. See this example: https://github.com/styfle/react-server-example-tsx/blob/master/tsconfig.json#L5 https://github.com/styfle/react-server-example-tsx/blob/mast...
- ng12 9y ago
  Flow is basically a linter, which I really don't like. If you run flow on an existing JS project it will find a few hundred not-really-bugs. That and the incredibly poor tooling (Flow runs as a separate server process) were enough to make me ditch it. On the other hand, if you use Typescript with the allowJs setting it's exactly ES6 plus optional types.
simplify 9y ago
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
octref 9y ago
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 9y ago
  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 9y ago
    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.
tabeth 9y ago
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 9y ago
  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.
anonyfox 9y ago
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.
- Rapzid 9y ago
  I believe there is a way to write type information out to decorators or something like that so you can get access to type information at run time.
  - anko 9y ago
    does anyone have any detail on this?
    - Rapzid 9y ago
      The last example on this page https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html
- smrq 9y ago
  Codegen your TS interfaces from your server endpoints. You don't need run-time enforcement if you have a compile-time guarantee that the endpoint you're hitting will return a specific type back. TypeLite (https://www.nuget.org/packages/TypeLite https://www.nuget.org/packages/TypeLite) can get you halfway there with C#. I used that for a while before eventually wanting more and rolling my own solution, which takes a WebAPI endpoint and generates typed fetch methods. It's not anywhere close to polished or reusable, unfortunately.
- Nemo157 9y ago
  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.
alistproducer2 9y ago
>Previously, TypeScript didn’t support compiling generators or working with iterators. I had no idea. That seems like a big deal, no?
- scanr 9y ago
  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.
msoad 9y ago
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 9y ago
  > 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.
styfle 9y ago
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
snugbug 9y ago
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 9y ago
  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 9y ago
    It is. I guess then you have to use the --strictNullChecks compiler flag to get the rest of the benefits
- RyanCavanaugh 9y ago
  Isn't this just the strictNullChecks flag?
- judah 9y ago
  Have you looked at TypeScript's non-null types[0]? It gives you compile-time checks for values that might be null. I personally love it and use it for all my projects. [0]: https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
- pininja 9y ago
  I use type sugar in my projects. This helps communicate what might be null/undefined. I haven't been satisfied with something like ts-optional since it wraps the object in a function (or class, or prototype?), making it harder to serialize to JSON. /** Represents optional values, just as F# does. */ export type Option<T> = T | null | undefined; /** Option operators. */ export namespace Option { /** Constructs a Some(value) option. */ export function some<T>(value: T): Option<T> { return value; } /** Returns true if the value is Some value and false otherwise. */ export function isSome<T>(value: Option<T>): value is T { return value !== undefined && value !== null; } /** Constructs a None option. */ export function none<T>(): Option<T> { return null; } /** Returns true if the value is null or undefined and false otherwise. */ export function isNone<T>(value: Option<T>): value is null | undefined { return value === undefined || value === null; } /** Recovers an Option<T> from JSON object representation. */ export function fromJSON<T>(json: any): Option<T> { return isSome(json) ? <T>(json[0]) : null; } /** Converts to a JSON representation. */ export function toJSON<T>(value: Option<T>): any { return isSome(value) ? [value] : null; } /** Unpacks with a default value. */ export function withDefault<T>(value: Option<T>, defaultValue: T): T { return isSome(value) ? value : defaultValue; } } EDIT: Forgot to mention, I got this from Gluon. https://github.com/Tachyus/gluon/blob/master/src/Gluon.Client/Gluon.ts https://github.com/Tachyus/gluon/blob/master/src/Gluon.Clien...
INTPenis 9y ago
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.
Too 9y ago
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
fahrradflucht 9y ago
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-TypeScript#generic-parameter-defaults https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...
saosebastiao 9y ago
Would the plugin system allow for things like conditional compilation or closure-like optimizations?
- orta 9y ago
  No, to my knowledge the plugin system won't allow extending the compiler's knowledge of new symbols inside a source file
skrebbel 9y ago
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 9y ago
  You still need to provide some polyfills
  - WorldMaker 9y ago
    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.
- tills13 9y ago
  I've replaced Babel all together for an app using webpack - I use the unfortunately named https://github.com/s-panferov/awesome-typescript-loader https://github.com/s-panferov/awesome-typescript-loader If there's something you really need in Babel, you can always transpile to ES6, then put it through Babel.
- mythz 9y ago
  Right I've never needed to use Babel, webpack + TS is now my choice combo. Being able to use latest ES6/7 features is one of the main reasons why I now use TypeScript for all my JS projects, even small ones that contain minimal Type annotations.
- Karupan 9y ago
  That's exactly what I've been doing since 2.1 came out. We get to use async/await, object spread etc but still get it compiled to ES5. Haven't had any trouble getting it working with React either. It did need some tweaking to the tsconfig.json file, but that's a one time setup.
homulilly 9y ago
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.
dkarapetyan 9y ago
Anders and team are like programmer whisperers. Every design decision has been a productivity boon.
- nojvek 9y ago
  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.
mosen 9y ago
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.
nojvek 9y ago
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.
eberkund 9y ago
I'm curious, what frameworks are people using TypeScript with? Is it mostly Angular or are people using it with others also?
- haapanen 9y ago
  We use both Backbone.js and React.
- theprotocol 9y ago
  I'm actually using it for the app logic/container in a riot.js app. Libraries like React/Riot/Vue are happy just being views in your Model-View-Whatever. Angular is another story.
- rexpan 9y ago
  React, AngularJS v1, basically everything that more than 100 lines of js code.
- WorldMaker 9y ago
  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).
xellisx 9y ago
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 9y ago
  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.
- jamespacileo 9y ago
  TypeScript isn't a higher level of JavaScript, it's ES6 with added features and types. Main purpose is to make JavaScript code easier to maintain, especially across teams. IMO the only way to go "higher level" is to use something like jQuery.
- deleted 9y ago
  [deleted]
mullsork 9y ago
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?
skocznymroczny 9y ago
I've been using Dart for a few months. What advantages does TypeScript have?

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

DanRosenwasser 9y ago
There's already a way to consume TypeScript through its API and inject a custom transform today, so a lot of the machinery is already in place.
Touche 9y ago
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 9y ago
  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.
- 15155 9y ago
  Much of this, IMO, is due to a lack of a type system. The maintenance nightmare comes from when behavior changes and you have no way of knowing about it - a type system staves off some of this.
rattray 9y ago
I hope so – so far it looks a lot less powerful. One aspect that's disappointing to me is that the AST they use seems fairly idiosyncratic; Babel's is quite close to the ESTree spec, and even easier to work with. Relatedly, it also doesn't look possible to swap out the parser, which Babel makes easy. I'd love to use the TS typechecker for a compile-to-js lang I'm working on ([0]), but would need to use my own parser. [0] http://lightscript.org http://lightscript.org
- DanRosenwasser 9y ago
  Hi Alex (I have an email from you that I have to respond to)! TS guy here. We've had discussions around this and the reason we use our own AST format is for compilation speed and editing scenarios, both of which our team really focuses on. I'll also note that incredible folks like James Henry have already written tools to convert TypeScript ASTs to the ESTree format[1]. I've heard it's been working well for using ESLint on TypeScript code. [1]: https://github.com/eslint/typescript-eslint-parser https://github.com/eslint/typescript-eslint-parser
  - rattray 9y ago
    Hey Dan! Yeah, prettier has also been working hard[0] towards TS support, frequently referencing typescript-eslint-parser (I haven't been involved). Personally I want to go the other way – ESTree to TS – so while the prior art is helpful, very little of the code could be reused. If TypeScript (or a fork thereof) exposed an option to use your own parser, an ESTree -> "TSTree" library could be used to map the output of any babel plugin to TypeScript. I'm sure you've discussed/considered this; presumably speed is a top concern. [0] https://github.com/prettier/prettier/issues/13 https://github.com/prettier/prettier/issues/13 and https://github.com/prettier/prettier/issues/1306 https://github.com/prettier/prettier/issues/1306

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)

deleted 9y ago
[deleted]
sheetjs 9y ago
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 9y ago
  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-in-JavaScript https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-i...
  - yathern 9y ago
    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.

myth_drannon 9y ago

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

wildpeaks 9y ago
It's a good thing, competition is a fuel of innovation :)
- myth_drannon 9y ago
  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.

chamakits 9y ago

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.

martijndeh 9y ago
I agree. Additionally, it looks like the comments feature is compatible with the JSDoc syntax. I'm not too sure about the return syntax though. This means I can start type checking some of the large and older JavaScript projects, all documented with JSDoc, of some of my clients. I'm eager to test this out. In my experience, in some organisations, it's hard to introduce TypeScript instead of JavaScript, because of reasons. For example, one of my clients made a bet on CoffeeScript back in the days, and that didn't work out, so now they are hesitant to adopt anything. Being able to introduce at least the type checking feature will start to drive change to this hesitation.
mattbierner 9y ago
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

macrael 9y ago

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.

msoad 9y ago
We did a very deep dive in comparison between the two before going with TypeScript. The biggest differences are: 1. Number of existing type definitions in DefTyped vs. FlowTyped and packages that provide typings. TypeScript has way more type definitions 2. Tooling, TypeScript has a much better tooling support 3. Project popularity: number of downloads, GitHub issues and pull requests etc. TypeScript is much more popular. Syntax and personal opinions was not part of our decision making process.
- nojvek 9y ago
  with the checkJs option, now you don't even need to rename your files to .ts, You can just use typescript as a nice typechecker and give you sane .js
freditup 9y ago
What es6 features were you looking for that TS didn't support? In general, it supports most stage 3 and higher ES proposals. (Note that TS doesn't polyfill methods; it only adds support for syntactic elements)
styfle 9y ago
I suspect you didn't set target to ES6 in the `tsconfig.json` file which would limit some of the features. If you don't specify, I think the default is ES5. See this example: https://github.com/styfle/react-server-example-tsx/blob/master/tsconfig.json#L5 https://github.com/styfle/react-server-example-tsx/blob/mast...
ng12 9y ago
Flow is basically a linter, which I really don't like. If you run flow on an existing JS project it will find a few hundred not-really-bugs. That and the incredibly poor tooling (Flow runs as a separate server process) were enough to make me ditch it. On the other hand, if you use Typescript with the allowJs setting it's exactly ES6 plus optional types.

simplify 9y ago

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

octref 9y ago

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 9y ago
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 9y ago
  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.

tabeth 9y ago

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 9y ago
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.

anonyfox 9y ago

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.

Rapzid 9y ago
I believe there is a way to write type information out to decorators or something like that so you can get access to type information at run time.
- anko 9y ago
  does anyone have any detail on this?
  - Rapzid 9y ago
    The last example on this page https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html
smrq 9y ago
Codegen your TS interfaces from your server endpoints. You don't need run-time enforcement if you have a compile-time guarantee that the endpoint you're hitting will return a specific type back. TypeLite (https://www.nuget.org/packages/TypeLite https://www.nuget.org/packages/TypeLite) can get you halfway there with C#. I used that for a while before eventually wanting more and rolling my own solution, which takes a WebAPI endpoint and generates typed fetch methods. It's not anywhere close to polished or reusable, unfortunately.
Nemo157 9y ago
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.

alistproducer2 9y ago

>Previously, TypeScript didn’t support compiling generators or working with iterators. I had no idea. That seems like a big deal, no?

scanr 9y ago
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.

msoad 9y ago

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 9y ago
> 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.

styfle 9y ago

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

snugbug 9y ago

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 9y ago
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 9y ago
  It is. I guess then you have to use the --strictNullChecks compiler flag to get the rest of the benefits
RyanCavanaugh 9y ago
Isn't this just the strictNullChecks flag?
judah 9y ago
Have you looked at TypeScript's non-null types[0]? It gives you compile-time checks for values that might be null. I personally love it and use it for all my projects. [0]: https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-nullable-types https://blog.mariusschulz.com/2016/09/27/typescript-2-0-non-...
pininja 9y ago
I use type sugar in my projects. This helps communicate what might be null/undefined. I haven't been satisfied with something like ts-optional since it wraps the object in a function (or class, or prototype?), making it harder to serialize to JSON. /** Represents optional values, just as F# does. */ export type Option<T> = T | null | undefined; /** Option operators. */ export namespace Option { /** Constructs a Some(value) option. */ export function some<T>(value: T): Option<T> { return value; } /** Returns true if the value is Some value and false otherwise. */ export function isSome<T>(value: Option<T>): value is T { return value !== undefined && value !== null; } /** Constructs a None option. */ export function none<T>(): Option<T> { return null; } /** Returns true if the value is null or undefined and false otherwise. */ export function isNone<T>(value: Option<T>): value is null | undefined { return value === undefined || value === null; } /** Recovers an Option<T> from JSON object representation. */ export function fromJSON<T>(json: any): Option<T> { return isSome(json) ? <T>(json[0]) : null; } /** Converts to a JSON representation. */ export function toJSON<T>(value: Option<T>): any { return isSome(value) ? [value] : null; } /** Unpacks with a default value. */ export function withDefault<T>(value: Option<T>, defaultValue: T): T { return isSome(value) ? value : defaultValue; } } EDIT: Forgot to mention, I got this from Gluon. https://github.com/Tachyus/gluon/blob/master/src/Gluon.Client/Gluon.ts https://github.com/Tachyus/gluon/blob/master/src/Gluon.Clien...

INTPenis 9y ago

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.

Too 9y ago

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

fahrradflucht 9y ago

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-TypeScript#generic-parameter-defaults https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

saosebastiao 9y ago

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

orta 9y ago
No, to my knowledge the plugin system won't allow extending the compiler's knowledge of new symbols inside a source file

skrebbel 9y ago

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 9y ago
You still need to provide some polyfills
- WorldMaker 9y ago
  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.
tills13 9y ago
I've replaced Babel all together for an app using webpack - I use the unfortunately named https://github.com/s-panferov/awesome-typescript-loader https://github.com/s-panferov/awesome-typescript-loader If there's something you really need in Babel, you can always transpile to ES6, then put it through Babel.
mythz 9y ago
Right I've never needed to use Babel, webpack + TS is now my choice combo. Being able to use latest ES6/7 features is one of the main reasons why I now use TypeScript for all my JS projects, even small ones that contain minimal Type annotations.
Karupan 9y ago
That's exactly what I've been doing since 2.1 came out. We get to use async/await, object spread etc but still get it compiled to ES5. Haven't had any trouble getting it working with React either. It did need some tweaking to the tsconfig.json file, but that's a one time setup.

homulilly 9y ago

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.

dkarapetyan 9y ago

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

nojvek 9y ago
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.

mosen 9y ago

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.

nojvek 9y ago

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.

eberkund 9y ago

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

haapanen 9y ago
We use both Backbone.js and React.
theprotocol 9y ago
I'm actually using it for the app logic/container in a riot.js app. Libraries like React/Riot/Vue are happy just being views in your Model-View-Whatever. Angular is another story.
rexpan 9y ago
React, AngularJS v1, basically everything that more than 100 lines of js code.
WorldMaker 9y ago
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).

xellisx 9y ago

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 9y ago
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.
jamespacileo 9y ago
TypeScript isn't a higher level of JavaScript, it's ES6 with added features and types. Main purpose is to make JavaScript code easier to maintain, especially across teams. IMO the only way to go "higher level" is to use something like jQuery.
deleted 9y ago
[deleted]

mullsork 9y ago

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?

skocznymroczny 9y ago

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