Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler.
I do this now for all my personal projects, in my opinion it's simpler, faster and closer to pure JS.
I regret every `infer` statement I've put in application code.
Grug phrased this elegantly:
I ask because for most of my projects there's at least some bundling going on, and in that case the added complexity of Typescript compilation is pretty minimal - with tools like Vite there is no added complexity, because JS and TS files are going down exactly the same pipeline, parsed by the same parser, etc. And I could get rid of the bundler, which would make some things simpler, but makes imports and deployment more complicated. For the scale of projects that I'm working on, bundling feels like necessary complexity.
I guess I'm trying to figure out if this is a useful form of minimalism for the sorts of projects I work on, or if this is the sort of thing that works for some projects but not others.
TS features don't need types to produce output[1] and this is supported by the compiler; it just doesn't have a CLI option.
Compiling without types is supported the compiler itself (this is what Babel does).
[1] Except const enum and export *
Can with JSDoc define types? And can you define generic types? To me that is the real power of TypeScript, being able to type every object you use.
But the one big annoyance is events - I've never found a satisfying way of writing a JSdoc that says what events a class emits, or what parameters the events have. Do you have a way of handling this?