I don't really like the idea of sprinking around 'any' to silence noImplicitAny problems.
Either put in the correct type or leave it as is. Placing 'any' in the code just fossilizes badness. Implicit any is just easier to accept, because when you finally have time to get serious you can disable it an write the correct types. You don't have to hunt for 'any' throughout the code.
We’ve forbidden the use of any specifically because it’s unwieldy. You can develop using ‘unknown’ until you’re finally ready to type something correctly. It works like any, but it doesn’t allow you to reassign your type. In our opinion any is one of the legacies of JavaScript that you should never, ever, use.
It’s not like you can’t of course, it’s just that it doesn’t “encourage” your developers to type things as they build them, which will eventually lead to shortcuts for a lot of people (myself included). Even if it doesn’t, it’s usually better for people to think about their types earlier rather than later, especially the less senior they are, or at least that is our experience. It’s much easier to get new people onboard when they aren’t doing “bad habits” that they then have to fix before their code is allowed to pass through the production pipeline.
I think it can make it easier to keep track of the work that needs to be done when explicit any (noImplicitAny) is used. I use them to monitor percentage of progress
typescript-eslint has a rule targeting explicit any annotations, and even several rules about assignments etc which are inferred as any. If you really want to include any in a strict-gradual migration strategy (I’m skeptical but could be persuaded depending on the baseline), you can use those rules as warnings or whatever makes the most sense. It’s definitely statically analyzable without a ton of bespoke effort.
"rg -w any", with an optional --count if want to count them rather than list their locations. It functions quite similarly to "unsafe" in Rust, and like "unsafe" I think ideally each "any" would come with a comment explaining why it's use is justified in that case (which is hard to enforce if the "any"s are implicit)
I agree completely that each any should be justified. That's why I'm against sprinkling it to silence errors. noImplicitAny with each manual any clearly justified is the desired end state of the migration.
Comments
I don't really like the idea of sprinking around 'any' to silence noImplicitAny problems.
Either put in the correct type or leave it as is. Placing 'any' in the code just fossilizes badness. Implicit any is just easier to accept, because when you finally have time to get serious you can disable it an write the correct types. You don't have to hunt for 'any' throughout the code.
We’ve forbidden the use of any specifically because it’s unwieldy. You can develop using ‘unknown’ until you’re finally ready to type something correctly. It works like any, but it doesn’t allow you to reassign your type. In our opinion any is one of the legacies of JavaScript that you should never, ever, use.
It’s not like you can’t of course, it’s just that it doesn’t “encourage” your developers to type things as they build them, which will eventually lead to shortcuts for a lot of people (myself included). Even if it doesn’t, it’s usually better for people to think about their types earlier rather than later, especially the less senior they are, or at least that is our experience. It’s much easier to get new people onboard when they aren’t doing “bad habits” that they then have to fix before their code is allowed to pass through the production pipeline.
I think it can make it easier to keep track of the work that needs to be done when explicit any (noImplicitAny) is used. I use them to monitor percentage of progress
How do you measure how many any's you got in your code?
How do you track where you have them? Just \bany\b regexp?
typescript-eslint has a rule targeting explicit any annotations, and even several rules about assignments etc which are inferred as any. If you really want to include any in a strict-gradual migration strategy (I’m skeptical but could be persuaded depending on the baseline), you can use those rules as warnings or whatever makes the most sense. It’s definitely statically analyzable without a ton of bespoke effort.
"rg -w any", with an optional --count if want to count them rather than list their locations. It functions quite similarly to "unsafe" in Rust, and like "unsafe" I think ideally each "any" would come with a comment explaining why it's use is justified in that case (which is hard to enforce if the "any"s are implicit)
I agree completely that each any should be justified. That's why I'm against sprinkling it to silence errors. noImplicitAny with each manual any clearly justified is the desired end state of the migration.