To be honest, I don’t know how deep you can go with just JSDoc. Can JSDoc tell you what the structure of an object must be based on the sequence of control flow

To be honest, I don’t know how deep you can go with just JSDoc. Can JSDoc tell you what the structure of an object must be based on the sequence of control flow and functions the object has gone through? Because that’s my favorite aspect of typescript in the abstract. I like that you get something like documentation as a computed property of your object based on what it has moved through over time. I like that I can feed an object to a generic function and see what it’s shape is when it comes out, all without actually running the object through the function or looking at the functions documentation. That sort of thing. I’m guessing from your comment that JSDoc can do things like prevent you from shipping if you try to feed a function an object that is incompatible with the function signature. TS can also stop you if it might be incompatible, which results in creating a provable system. Edit: you can also use typescript (the compiler) with JSDoc annotations instead of typescript (the syntax). It occurs to me that this might have been what you meant. If so, and you’re writing typescript conforming JSDoc, then I think the only difference is (mostly) just a philosophic one. Do you write ts syntax and this “force” the code to be compiled/checked before it can run (except not really because lots of people are separating compile and build these days), or do you note that it’s going to end up as js anyway and so just write js that you can use with the ts compiler. If you’re in the second camp, then I guess the benefits would be: - built type defs that you can share with consumers of your code…perhaps you can build these even with JSDoc? - early adoption of ECMAScript features, if you’re into that sort of thing, without needing to worry about if it’s supported on all your targets yet (ie, like Babel)