| ▲ | TheRealPomax a day ago | |||||||||||||||||||||||||||||||
> Had to explain to my employer attending that it is still typescript "is" is doing a lot of heavy lifting there: JSDoc and TypeScript are two different ways to explicit prescribe typing in a way that tooling can use to determine correctness. The TS syntax is _far_ more powerful, but JSDoc can do most of the common TS use cases, for folks who want to stay in JS land while still benefiting from type tooling (either invoked or straight up built into the IDE). | ||||||||||||||||||||||||||||||||
| ▲ | culi a day ago | parent | next [-] | |||||||||||||||||||||||||||||||
> in a way that tooling can use to determine correctness. As I pointed out in the article, the "tooling" is exactly TypeScript language services. If you are using JSDoc and you get squigglies or intellisense or any other similar features, you are using TypeScript. You can copy-paste basically any bit of TypeScript into a JSDoc comment and it will work. JSDoc supports any non-runtime feature of TypeScript (so not enums). Even generics! You can even reference TypeScript utility types! The whole point of this article was to correct the idea that JSDoc is not TypeScript. It absolutely is! There's almost nothing you can't define in JSDoc that you can't define in a .ts file. Albeit with a sometimes clunkier syntax | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
| ▲ | Sammi a day ago | parent | prev [-] | |||||||||||||||||||||||||||||||
In practice today JSDoc 100% completely and utterly always is Typescript. It might not have been so originally. It might still be possible to do differently. But in practice today you are getting Typescript in your JSDoc with the out of the box tooling that is everywhere. | ||||||||||||||||||||||||||||||||