[jannes]

I love TypeScript. I started using it around v1.0. Microsoft has hit some gold with it.

When I first started using it I had lots of `any` in my code (like the Google employee is describing here). But over time it really starts being extremely clean.

[radicalbyte]

I started around 0.7/0.8, it was already such a fantastic product back then. It's just fantastic, Javascript on steroids.

[Rychard]

I don't have a significant amount of experience with TypeScript, but even from my limited experience I agree that it's a fantastic product. That said, at $JOB we (unfortunately) have a fair amount of production code written in TypeScript 0.9 which nobody has ever upgraded, and simply won't compile on a more recent version. It's been that way for years now, and every attempt to bring it up to date has been met with failure.

It may be an overly broad request, but I'd be very interested if anyone had any suggestions for how we might go about performing such an upgrade in an iterative manner. My understanding is that pre-1.0, TypeScript went through a number of breaking changes (as would be expected of any pre-release software), but I've never found a complete list of what those breaking changes were.

[jannes]

You can see a list of all changes in the "What's New in TypeScript" document on GitHub:

https://github.com/Microsoft/TypeScript/wiki/What's-new-in-T...

And a list of breaking changes here:

https://github.com/microsoft/TypeScript/wiki/Breaking-Change...

They both go back until v1.1. For older changes you can check the blog:

https://devblogs.microsoft.com/typescript/announcing-typescr... https://devblogs.microsoft.com/typescript/announcing-typescr...

Anyway, it's hard to say what you need to do to get your code to compile on the latest TypeScript version without knowing what some common compile errors are in your code.

Here are some guesses:

1. The way you obtain type definitions for third-party packages has changed. It used to work with /// <reference> and tools like nuget or TSD (TypeScript definition manager). But now it works with npm in the @types namespace and some npm packages even include definitions themselves now.

Of course, updating to the latest type definitions would mean that you have to upgrade to the latest versions of the third-party libraries as well. Otherwise you have to find a way to keep working with the old definitions for the respective library versions.

2. Pre-1.5 TypeScript had something called "internal modules" which were renamed to "namespaces" and are generally discouraged now. Hopefully your code is not using that feature.

https://www.typescriptlang.org/docs/handbook/namespaces.html

3. tsconfig.json. I don't remember when they introduced it, but you likely need to create this file and tweak the settings

[WorldMaker]

> 2. Pre-1.5 TypeScript had something called "internal modules" which were renamed to "namespaces" and are generally discouraged now. Hopefully your code is not using that feature.

Related to this, the TypeScript pre-1.0 import/export syntax for "external modules" was grandfathered in, but the semantics changed alongside the "internal modules" changes in 1.5. So pre-1.0 import/exports still mostly "compile" in post-1.5, but have very different semantics and that can often cause a lot of downstream module shape headaches, depending (and exacerbated by) the module format you are targeting.

A first pass making sure to rewrite all import/require/export statements can save you a lot of work later, even though it won't directly cause compile errors. You can get some compile errors by making sure you try to compile to a "proper" post-ES2015 module format (--module esm or --module es2015 or --module esnext even). There's also tslint rules such as "no-import-requires".

[pas]

So, because it currently "works", it should "safely" compile by adding many `any`s. (No Implicit Any, and other strictness flags set to false.)

Then it's a matter of cleaning them up.

But usually, at least in my experience, the problem is the libraries and their API, which used to be very much full of any in those dark times.