2 ms·
The list of things jsdoc cannot do is long but a simple example is overloading, you cannot express this[1] in jsdoc, and if you need to reference .d.ts files yo
by epolanski 11mo ago
The list of things jsdoc cannot do is long but a simple example is overloading, you cannot express this[1] in jsdoc, and if you need to reference .d.ts files you're back at using TypeScript, so the point of JSDoc was...?
If you need precise return typing, conditional types, literal values, etc, you aren't going far if anywhere with JSDoc.
[1] https://shorturl.at/pg5dL https://shorturl.at/pg5dL
- g947o 11mo agoThis specific one is actually supported since TypeScript 5.0: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#@overload-support-in-jsdoc https://devblogs.microsoft.com/typescript/announcing-typescr... But not properly documented (https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html https://www.typescriptlang.org/docs/handbook/jsdoc-supported...), which shows how much Microsoft neglects JS + JSDoc workflow. Github issues have been created a long time ago, but nothing has been done so far. Apparently Microsoft is too busy with their AI slop to work on actually useful stuff.
- efortis 11mo agoThere a few points in favor of TS types in jsdoc (in order): 1. not having to type everything (many types are not helpful) 2. makes code less dense (and they can be rendered in HTML) https://x.com/efortis/status/1989776568676221137 https://x.com/efortis/status/1989776568676221137 3. not needing a compiler (browsers don't support TS) I think the main jsdoc caveat is around private types. About 1, IDK if there’s a way to set up TS for that.