TypeScript Blog

I was concerned that it would be difficult to use the new `--strictFunctionTypes` flag due to all the 3rd party typings not conforming to this flag. However, sandersn fixed[0] many popular packages not long after this feature landed. I've been using TypeScript for 5 years[1] and it has been a great experience,! Even these (occasional) "breaking" changes are relatively easy to navigate. [0]: https://github.com/Microsoft/TypeScript/pull/18654#issuecomment-336274… [1]: https://blogs.msdn.microsoft.com/typescript/2017/10/02/typescript-turn…

It's very nice to see all of this consolidation going on in the Typescript ecosystem. For example Babel 7 shipping with direct Typescript support back in August, https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-… I am a Typescript convert myself and would suggest any daily JS developer give it an honest try.

Ah, I didn't realize this, very cool collaboration! For those who are reading this and might find it helpful, here's a link to the official blog post on the work: https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-…

They are independent, so you could read two blog posts, one for Babel 7 https://babeljs.io/docs/en/v7-migration and one for TS https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-…

TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-type…

I hope the work they did with the Babel team with help with this. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-…

Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6. Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade. The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-…

It's quite impressive how much TypeScript has improved in the last year: https://blogs.msdn.microsoft.com/typescript/ Kudos to the team.

That is not true at all! Flow was announced November 18, 2014: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-typ… Typescript got --strictNullChecks with Version 2 which was announced July 11, 2016: https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-type… Even if I'm being charitable and look for the date when the PR (https://github.com/Microsoft/TypeScript/pull/7140) was merged, we'd only get April 2016.

TypeScript is now incremental in that way: https://blogs.msdn.microsoft.com/typescript/2017/04/27/announcing-type…

The new --strict option might come in handy too: https://blogs.msdn.microsoft.com/typescript/2017/04/10/announcing-type…

There was a lightning talk on TypeScript at EmberConf that also gave a status update on how TS and Ember work together: * https://www.youtube.com/watch?v=ZCHFjGSCqP4&feature=youtu.be&t… It looks like full support could be landing soon. I know TS 2.2 added flexible enough class modeling to handle Ember's object system: https://blogs.msdn.microsoft.com/typescript/2017/02/22/announcing-type… Of course we're attacking that from the other side as well, and experimenting with native ES classes in Glimmer.

V2 is currently in beta. > In the coming weeks, a more stable release candidate will be coming out, with the final product landing not too far after. -- https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-type…

TypeScript 2 adds Easier Module Declarations[0]. So if a library doesn't have a type definition, you can silence errors by adding: declare module "some-module" Does that help? 0: https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-type…

> This release includes plenty of new features, such as our new workflow for getting .d.ts files[0] Does this mean that using Typings is no longer necessary, or is there some additional benefits that Typings still offers? 0. https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-d…

Posted today https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-d…

async/await has been in TypeScript for a while, but currently depend on generators, so don't down-level to <= ES5 emit (that work is in progress). With the latest Node releases and modern browsers supporting generators today, you can target ES6 and use async/await today if you can target those environments. https://blogs.msdn.microsoft.com/typescript/2015/11/03/what-about-asyn…

Unions were added in TS 1.4, over a year ago. https://blogs.msdn.microsoft.com/typescript/2015/01/16/announcing-type…

Also, Intersections were added in TS 1.6, last year: https://blogs.msdn.microsoft.com/typescript/2015/09/16/announcing-type… They seem to be moving at a decent, agile pace to improving/expanding upon the algebraic sides of the type system.

If you're already using VS Code, I expect you'll find TypeScript support to be much, much nicer, since VS Code is the not-quite-official editor for TypeScript programming. VS Code is written in TypeScript, and I believe the TypeScript and VS Code teams (both at Microsoft) collaborate with each other to improve the developer experience of the two used in combination. For example, here are some TypeScript release notes showing the improvements to the TS language service and how they manifest in VS Code: https://blogs.msdn.microsoft.com/typescript/2018/05/31/announcing-type… TypeScript has a nice architecture that provides a language service that can be used by any editor, but my impression is that VS Code is the "flagship" editor that gets these features first. I personally use WebStorm, and I find its TypeScript support much better than its Flow support in various ways (though I haven't tried Flow in a while). Imports get added automatically, autocomplete is fast and has better results, navigation just works, etc. Part of this is historical: WebStorm supported TypeScript first, and was hesitant to support Flow during the long period of time when Flow didn't work on Windows. It now has Flow support, but I think it's just not as polished, and I don't see it come up as much in the release notes.

The commit in question, made on 16th July, uses the term "OfficeISS". I can find no mention of this online. Is this a straightforward code-name for their project to re-write their major apps in React, mentioned in the following tweet? https://twitter.com/TheLarkInn/status/1006746626617008128 I asked for clarification on how they were approaching macOS support in React Native, both: 1) in that Twitter thread (to no answer): https://twitter.com/LinguaBrowse/status/1006834843416657920 2) and in the subsequent Reddit discussion: https://www.reddit.com/r/programming/comments/8qqhlz/office_365_ms_tea… (to an answer ignoring the macOS part of my question). Microsoft are clearly going all-in on React Native: 1) TypeScript 3 has plenty of oddly React-specific features (e.g. defaultProps and PropTypes support): https://blogs.msdn.microsoft.com/typescript/2018/07/30/announcing-type… 2) react-native-windows is thriving: https://github.com/Microsoft/react-native-windows 3) WinObjC is looking formidable: https://github.com/Microsoft/WinObjC I think the future is bright for Microsoft, cross-platform development, and the React universe..!

They've finally begun backtracking on function parameter bivariance. https://blogs.msdn.microsoft.com/typescript/2017/06/12/announcing-type… They still think they're right: "Our experience has been that users generally don't run into issues with this all that much", but they've started to "tighten[] things up and compare[] the parameters which are callbacks specifically". I'm just so excited and annoyed that they've finally partially admitted they're wrong. Double annoyed that we're still on TS 1.8 :( I just don't understand function parameter bivariance. It's not just that it's wrong (if it was just theoretical I wouldn't've noticed), it's that it keeps letting bugs through. You simply can't refactor the code and then fix it till there's no errors because you'll run out of errors before you run out of things that need changing. Or adding features in React+Redux, can you get it to help you? Nup. At least that's a specific point you can remember to check.