Currently there are around 350 anys by my rough estimation, and also some just plain-old type errors. Is there currently a strategy in mind for cleaning some of these up? Should we discuss one?
Love where you're heads at @lyleunderwood
I would like a setup where devs can use any during development, as long as they remove them before merging to master.
I think this could be accomplished with eslint by setting:
"@typescript-eslint/no-explicit-any": "error",
I think that's a good idea, then we need to think about transition strategy. Obviously if we turned that rule on right now, it would just break the build. Correctly typing each of those pieces of code, however, is not going to happen all at once or overnight.
My recommendation would be to turn on the rule creating a ton of errors, then run a script which adds a comment like:
// FIXME: Correctly type this! (link to documentation or wiki page here?)
// eslint-disable-next-line @typescript-eslint/no-explicit-any
above each instance of this error. This encourages incremental resolution of this issue.
The other element of this is ensuring that all the fundamental data types are worked out and available for use, because otherwise it's basically impossible to correctly type everything.
How are you guys actually _running_ tsc? Just in the build / test / watch scripts with rollup? It would be nice to add a "check-types": "tsc --noEmit", script to the root package.json, so that types could be checked independently of building etc., for development work on types specifically. It's unclear to me right now what types actually get checked when.
Depending on my configuration the lowest number of type errors I've been able to get is 42 when running npx tsc --noEmit from the project root. Should I expect fewer here?
"@typescript-eslint/no-explicit-any": "warn",
Would be better while transitioning. That way devs can see the hundreds of anys that need changing without breaking the build.