Supporting TSDoc in `deno doc` and dts emit

[lucacasonato]

Right now we only support TS type annotations in .ts files for both deno doc and fast check emit. We do not understand type annotations in TSDoc comments in .js files as of yet. We could do this, but it would require significant effort:

• New JSDoc / TSDoc parser that can handle parsing type expressions
• deno doc needs to understand type expressions in TSDoc
• Fast check needs to understand type expressions in TSDoc
• Fast check needs to emit type expressions in TSDoc to .d.ts files

[hrgdavor]

This is a blocker for me. I hope there more others like me regarding this issue, so there is incentive to tackle this.

I want to be typescript friendly, but refuse to to use it directly. It is my personal preference.

[theengineear]

^^ Having similar issues. I have a package where I define all types via JSDoc in .js files and then emit .d.ts files. I believe that I should be able to do this in such a way that shouldn’t flag my package as having slow types. I’m struggling with understanding whether I’ve somehow done something wrong or if I’m being incorrectly flagged as having “slow types”.

Thanks!

[hrgdavor]

Trying not to spam. I am interested in publishing some libraries and using jsr to improve docs and types quelity, but this is show stopper for me. I do see some progress in netflix/x-element that looks promising for this ... looking fwd to more progress.

[sergey-shandar]

I have the same issue. One of the workarounds would be to generate .d.ts files using tsc before publishing a package. But it looks like I can't associate the generated .d.ts files like I could do in package.json:

...
"exports": {
    "./a": { "types": "./a.d.mts", "import": "./a.mjs" },
...

I have tens of .mjs files in my mono-package, so // @ts-self-types="./types.d.ts could be problematic.