3 ms·
Although it's more verbose, it makes code less dense because it lives outside the function parameters. Also, it's not a super limited subset. For instance, you
by efortis 10mo ago
Although it's more verbose, it makes code less dense because it lives outside the function parameters.
Also, it's not a super limited subset. For instance, you can write types in .d.ts the IDE uses those types in jsdoc out of the box.
- epolanski 10mo agoThe 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 10mo 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 10mo 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.