[steadicat]

Yes. As a matter of fact, I'm currently working on a large JS codebase that is a decade old. We switched over all the code to TypeScript in one go, and we are gradually fixing the type errors over time. VSCode does an excellent job of showing you type annotations and type errors inline, so the typing is very useful even if you have thousands of errors elsewhere in the project and never even run the type checker globally.

In fact, out of the dozen or so TS codebases I've worked on, I've rarely seen one completely free of type errors. And yet no team has ever doubted the value of the type system. It's a very pragmatic approach which works very well for many teams in my experience.

[qwer]

I just finished something similar: http://caines.ca/blog/2018/12/11/a-javascript-to-typescript-...

We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts files, so we are indeed completely free of type errors now. We only have 50 cases of (explicit) `any` in 85K+ LOC and they're in type def files.

Let me be the first person you've met to doubt the value of the type system. I do like the in-editor support, but you pay for it with about 25% more code.

I'm certainly not advocating undoing it, but I personally wouldn't do it again (though the team has mixed opinions).

Just curious: What's your test coverage like?

[robocat]

So how many errors were uncovered, and how serious could they have been?

[qwer]

It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.