1. and 2. nice reasoning. I have been considering adding Typescript recently. Mainly as I sometimes encounter bugs on e.g. an options object where a property is named incorrectly. That tends to lead to hours of debugging, so it'd be reasonable to start using it.
Re: third party code: I'm not against third-party libs. But what I tend to prefer is having control over my code. This makes me faster in building and maintaining. I'm a solo freelancer. I can't afford to wait three days for a PR upstream to be merged.
Also, I like to create my own little dependency. That way I have a way to create separate and loosely coupled APIs (shareable) and control.
Of note, Typescript is a heavy lift to add to, really port, an existing codebase. Flow can be sprinkled into an existing codebase easier if that's your goal. Once you understand the way the types work (in particular Generics) they're somewhat interchangeable.
New codebases for us use Typescript, extending existing work we use Flow that can be backported in easier.
On the other side of this point, I've used typescript and converted a major project to use it and it was fairly simple. The main thing you should start with for low hanging fruit is database queries. Make sure your database query functions are typed and it'll make the rest of your code much easier to write even if the rest isn't in typescript. Start getting types into the places where the data is coming from. The source of the data.
Re: third party code: I'm not against third-party libs. But what I tend to prefer is having control over my code. This makes me faster in building and maintaining. I'm a solo freelancer. I can't afford to wait three days for a PR upstream to be merged.
Also, I like to create my own little dependency. That way I have a way to create separate and loosely coupled APIs (shareable) and control.