Not really, not completely. kondo's system for type checking is a bit patched together. It has to put in a custom function every time it has to do a conditional type check, for instance.
Kondo has a custom function for core.into that says to make the return type the same as the type of the collection passed in as its first argument. Already there is a ticket on their JIRA board to add that to another function, and it doesn't follow suit on a variety of other functions either, like the function inc. If you pass an int to inc, Kondo doesn't know if the output is still an int.
This code: (nth [1 2 3] 1.5) throws an error in kondo (which is incorrect btw, nth is defined for non-integers)
But this code (nth [1 2 3] (inc 0.5)) comes through with no error.
If this continues, kondo will have to end up with a huge amount of logic, that doesn't necessarily belong in their codebase.
If a user wanted to implement or extend logic like that, it would be difficult to do so. There is no easy and well understood means of defining that. I was hoping spec would grow to become a standard way for developers to encode necessary type logic within their own codebases in a TypeScript-y way. For instance, if it was important in your codebase to define a collection as a collection of ints, or a collection of some custom type for your database, that would get communicated to kondo, and it would be able to perform logic on that, and see several transformations down the line if something will fail. Spec and Malli already have some systems to do that, but kondo doesn't have the logic yet to complete it.
I am unsure if the appropriate logic for making this kind of analysis belongs in kondo itself, or if it belongs somewhere in the clojure codebase, since it is solely dependent on clojure's api. Nor do I know if spec or spec2 are the right places to hold it. That's why I posted this question here.