[playground] No parsing of TypeScript type information?

[microsoft]

[playground] No parsing of TypeScript type information?

[liamross]

I understand that perhaps parsing the actual TypeScript code is outside of the scope of what TSDoc is trying to accomplish, but it was definitely something I hoped would be included since I first noticed this project gaining some traction.

In the README it says:

The majority of the standard JSDoc tags are preoccupied with providing type annotations for plain JavaScript, which is an irrelevant concern for a strongly-typed language such as TypeScript.

However, the fact that my documentation will have zero indication of the type of a parameter means that this could never serve as a replacement for JSDoc for me personally. If I write a library in TypeScript and it is consumed by a JavaScript application, I would like for there to be typings in the documentation, and not require that people are relying on IDE tooling or digging into the package to find types.

The first thing that drew me to this was the idea of it parsing types from the code to save the redundant declarations in the documentation.

Is there a reason why this is excluded from this project? It seems like a gap to not include typing in documentation personally.

[octogonz]

The TSDoc playground doesn't include a TypeScript compiler at all. (One of the "features" of the @microsoft/tsdoc library is that it's completely self-contained and doesn't require any other library dependencies. So you can easily use it with other compilers besides TypeScript.)

The playground admittedly doesn't make this very obvious however, since:

1. We include TypeScript source code in our samples, and
2. The Monaco texteditor applies syntax highlighting to the TypeScript code

We should make this more clear, but I wasn't sure what's the best way to do that. Some ideas:

• remove the TypeScript code from the samples
• disable syntax highlighting for the TypeScript language
• add a text disclaimer explaining that the TypeScript code is only being shown for illustrative purposes

@iclanton FYI

[Gerrit0]

TSDoc is only concerned with parsing comments. TypeScript provides the type information. Any documentation generator will need to interact with the TypeScript compiler API to iterate through documentable nodes and then parse their comments to TSDoc. Take a look at the advanced demo source to see one way this could look.

[octogonz]

Here's the other example that @Wenzil gave in #116:

/**
 * Some sample class
 */
export class MyClass {
    /**
     * Returns the average of two numbers.
     */
    getAverage(x, y) {
        return (x + y) / 2.0;
    }
}

We need to improve the playground UI to make it clear that this is not an expected input.

[octogonz]

Alternatively, we could actually support full TypeScript source files as input. Maybe the "HTML" tab would dynamically change to render whatever comment your cursor was inside. That's probably a much more involved change, though. ;-)

[Wenzil]

Thanks for the replies. I understand the scope of the library better now. I like the suggestions to state the expected input more prominently, both in the source README.md and the playground

[octogonz]

If the playground code sample looked like this:

/**
 * Returns the average of two numbers.
 *
 * @remarks
 * This method is part of the {@link core-library#Statistics | Statistics subsystem}.
 *
 * @param x - The first input number
 * @param y - The second input number
 * @returns The arithmetic mean of `x` and `y`
 *
 * @beta
 */

instead of this:

/**
 * Returns the average of two numbers.
 *
 * @remarks
 * This method is part of the {@link core-library#Statistics | Statistics subsystem}.
 *
 * @param x - The first input number
 * @param y - The second input number
 * @returns The arithmetic mean of `x` and `y`
 *
 * @beta
 */
function getAverage(x, y) {
    return (x + y) / 2.0;
}

Would that have been more clear? If we do that, we could also report an error if there is any text after the comment.

[Wenzil]

Yeah definitely more clear. Error could reported only if there is a second opening /** to indicate that TSDoc only expects one comment block at a time.

[octogonz]

Hmmm... I had not thought of this requirement, where you want to work in TypeScript but accomodate developers who code in plain JavaScript.

But if I were doing that, I definitely wouldn't want to ask our devs to write all their type information twice (once in the code, and again in the TypeScript doc comments). Wouldn't it make more sense for the compiler to emit type annotations into the .js files, based on its own type analysis? That would save a lot of human effort.

In this case technically the .d.ts files could get TSDoc emitted into them and the .js files could get JSDoc. But obviously we would want to align the two as much as possible...

We should open a separate GitHub issue since this question is unrelated to the playground.

[octogonz]

@fastfedo encountered the same confusion in #152 (comment) . He gave a couple suggestions:

Two things might have helped me here:

1. Documentation examples in/linked from the README that show usage with different TypeScript constructs (interface, type, class, enum, etc).

2. A note on the TSDoc playground that it's not actually parsing TypeScript, or that only the first
   comment is being parsed, as you stated above. So the playground is not a place to explore how
   more complex types would be documented.