Announcing TypeScript 3.2 | Hacker News Reader

Announcing TypeScript 3.2

blogs.msdn.microsoft.com

TypeScript is amazing. Not just from a feature point of view, but also from a tooling and usability point of view. The flexibility of tsconfig.json and the sheer volume of @types packages has allowed my workplace to introduce it to our core JS codebase over the past 2 years, with pretty much 0 hiccups. It's actually annoying hopping into Go and Python and not having such a powerful type system at my disposal.

I'm not sure how the TS project itself is organized, but I wonder if the type system could be adapted to provide static types to other languages, like Python.

As for 3.2, I'm happy to see the narrowing for tagged unions. I ran into a small annoyance with this a few weeks ago. Looking forward to variadic types in a future release!

> Go and Python and not having such a powerful type system at my disposal.

Python may not have that great type support. But I found Go type system to be quite good. Can you elaborate

The biggest annoyances are the lack of exhaustive pattern matching and the lack of sum types. I say annoyances because its possible to get most of the behavior for sum types with interfaces but a lot more boilerplate must be written. And, while Go offers no exhaustive pattern matches, in practice the use of a default switch that returns an err works OK. But at the end of the day, I find my colleagues a lot less elegant and rigorous with their Go types/structs compared to their Typescript code because of the additional boilerplate, which makes me think language ergonomics around types makes a difference in code quality around data modeling. Its not an monumental chasm, but it exists.

Okay I'm finally ready to take a shot at TS.

Any suggestions on the best guide for "incrementally, politely, unopinionatedly introducing TS to an existing JS web application"?

Last time I gave it a shot I had to make a lot of changes upfront so I walked away from it.

Add a `tsconfig.json` and turn on `allowJs` for starters. If you're already using Babel, you can check out the Babel/TypeScript Starter for some guidance on quick and easy integration [1].

Then create a `types.ts` file for types that are used throughout your project, and as you see common data structures being used in your program, declare `interface`s and `type` aliases there. Then you can switch your `.js` files to `.ts`/`.tsx` files one-by-one and add types (or even add types via JSDoc and then convert those to `.ts` files when you're ready).

Eventually for the best experience, you can start switching on strictness modes. `strictNullChecks` is a pretty great one to use early on. Then `noImplicitAny` and `noImplicitThis` when you have pretty good type coverage. Finally you can turn on the full `strict` flag which will turn the others on, which are pretty easy to integrate into your codebase (and which you can turn off individually).

[1]: https://github.com/Microsoft/TypeScript-Babel-Starter

Wow thanks. That sounds like pretty much all I need to know at this point!

I can fully second this approach. We migrated away from a plain AngularJS application in 2016. The sheer number of bugs we have since been able to prevent by the (ever improving) strictness checks of Typescript is staggering.

And all that, with what I believe is excellent documentation and support. I mean you're getting a getting started comment from the lead managers on the project

Thanks Daniel!

Why did it take you so long! :)

Good question! I wasn't experienced enough to realise its value on projects where it would have been great. And since then I haven't done any projects that it makes sense for: Smaller projects built by a one-person team that value quick experimentation and iteration above all else. Now that my work has shipped and the robots are happily doing their robot things, I can go and harden it all before the team grows significantly next year.

TypeScript seems like a perfect tool to help structure a codebase prior to bringing on more developers.

It'll be interesting to see where TS goes over the next couple of years. They seen to have a short roadmap.

The proposed @types scaffolding seems interesting for solving issues with untyped libraries. Maybe the focus will be how do we actually get all the code typed rather than resorting to 'any'.

Side note, quite amusing: https://twitter.com/kitsonk/status/973651805950242816

Reply on news.ycombinator.com