Hacker News new | ask | show | jobs
by lucasyvas 1133 days ago
Isn't casting with JSDoc impossibly ugly though? The inputs/outputs of a function signature are not the only times a type annotation is needed in TS.
2 comments

Type casting (type assertion, in TS parlance) is incredibly annoying to do in JS/JSDoc. In an ideal world, that would be a distinct advantage because type assertions are typically, or at least should be, considered risky: it’s a brute force way to ignore type errors. In the real world, you might find you have to correct inferred types, sometimes because they’re naively wide (eg, so many DOM interfaces devolve from HTMLElement to Element for no obvious reason!), but also often because they’re overly narrow (eg, so many dynamic collection member accesses completely ignore null safety, again for no obvious reason).

In practice, what I’ve found is that the hassle of adding type assertions even if they’re correct nudges me to write worse code (“to appease the type checker”) in JS/Doc than it does in TypeScript syntax. I don’t think TypeScript syntax makes me feel more relaxed about writing unsafe type assertions, but I’m probably an outlier because I pretty much only do that when I’ve exhausted every other available/known approach.

Type imports are the worst.
Do you mean native JSDoc namepaths like

    /**
     * @type {module:look/here~MyType}
     */
or TypeScript "JSDoc" imports like

    /**
    * @type {typeof import("./look/here").MyType}
    */
or both?
I meant star type imports or rather lack of it.