Tom MacWright

The `@returns` implementation follows the JSDoc spec ( https://jsdoc.app/tags-returns.html ) which doesn't include default values or nesting. We could support a more expressive syntax here, but it'd need to be...

True, for the React class component that shouldn't be the signature. But to answer the core question: this isn't very obvious in the `new Foo()` because `Foo` doesn't have any...

It isn't supported at this point, for sure. This project mainly tracks [usejsdoc](https://jsdoc.app/tags-typedef.html), which doesn't include this syntax, whereas I'm guessing this is a TypeScript addition to the jsdoc idea.

Yep, a full and complete plugin system is still something this project needs. If someone wants to help, I'm happy to review and merge the PR.

I've already responded, above, and the answer's the same - if someone wants to help out and implement the feature, I'm happy to review and merge the PR.

Hello! Re: main question about modifying themes: - The files in `src/` are source files: they're written in ES6 with [Flow](https://flow.org/) annotations, so they won't run uncompiled. They're compiled to...

The `html-example` is just the default theme from several documentation.js versions ago, which was replaced by the current theme, and it was generated by the normal `build` command. The APIs...

I'm not sure about this change - I'd welcome some input from other folks yay or nay. Essentially, I think it'd be preferable to represent things like ``` class Foo...

Like the rest of the JSDoc properties, I'm very open to PRs implementing the rest of this. That said, would want to clarify this a bit: JSDoc has this [concept...

To clarify this a little bit: if your module has types, and a Store, what is it exporting? Like if someone writes `var theValue = require('your-module');`, what value is stored...