I already feel like living in JS land is coding against a moving target, so refactoring is something that happens extremely often anyway. I wrote and manage a few projects that are several hundred thousand LOC each and my strategy has just been to allow JS and TS to coexist but if I touch a JS file, the first thing I do is refactor it to TS, and then start whatever new work I needed to do. It usually goes pretty quickly unless you have code that was hacked together or designed weirdly in the first place, then I treat it as a good opportunity to do small refactors with types to just clean things up in general. The TS refactor has been going on for maybe a year and a half now and is mostly complete, and I'd say this approach has worked quite well. Maybe if you're working on a larger team you'll need to co-ordinate a little more with when types can be slapped onto existing code.

Just as an aside, the amount of bugs I've found just by refactoring to TS is incredible, the compiler has made me aware of edge cases that I hadn't thought of. Just adding types to old code and getting red squiggles telling me why it won't compile has taught me quite a lot about random aspects of JS that I've never considered.

Yes, the incremental refactor does appeal as a solution and we have been considering it.

Two potential drawbacks that were brought up are when there's a business "priority", the refactor will take a backseat, especially if the file is fully in JS.

The other is that with a larger codebase, this could take a year or even more and still not be fully done. But this is mitigated to a large extent by the fact that TS and JS can coexist and the benefits of a TS file are immediately available.

Thanks for your input!

Shameless self promotion, I did exactly that, blog post explains it:

https://chrisfrew.in/blog/converting-a-large-project-from-ja...

This method does have some caveats, but can get your a sort of starting point using TypeScript for any sized JavaScript project.

Thanks, will pass it to the team as well!