You can get a lot of mileage out of ESLint + typescript-ESLint + various other plugins. It's more of a "choose your own adventure" kind of experience, but the d

You can get a lot of mileage out of ESLint + typescript-ESLint + various other plugins. It's more of a "choose your own adventure" kind of experience, but the defaults are a good start, and if you're looking for cyclomatic complexity and all that jazz, there's various plugins that can calculate that. And the typescript ESLint plugin is great because it uses the types as part of the hints, which is great for finding places where you no longer need optional chaining, or where a condition is always true/false because you forgot what types things were. That said, I tend to take a much more lean approach to linting these days. I try to only include lints that are actionable, likely to lead to real bugs, and have no false positives. Everything else feels like it's better handled in code review. If you don't know why your function is too complex and difficult to read, I don't want you to rewrite it just to satisfy a robot that's following arbitrary rules! I want to be able to have a discussion with you about proper techniques for splitting apart code. But there's definitely people who go the other way entirely and build incredibly strict ESLint configurations, so looking for those might help you if that's what you want.