Coexistence with the compiler's JSDoc-in-JavaScript feature

[octogonz]

I'm moving @seanpoulter 's question into its own issue:

What's the long term plan for TSDoc? Will we be able to use it to annotate vanilla JavaScript like the current JSDoc support? In those cases the it's crucial to be able to declare an interface in the comments or document @param properties.

Some background: The TypeScript compiler allows plain *.js files to be compiled alongside with *.ts files, and it will parse certain JSDoc type annotations and incorporate them into the type system.

Some design questions:

• Beyond the TSDoc design goal of maintaining the look+feel of JSDoc (and CommonMark), does JSDoc-in-JavaScript imply any special considerations for TSDoc syntax?

• Would TSDoc and JSDoc-in-JavaScript really need to be parsed by the same documentation pipeline?
  (Or are will the *.js files generally be legacy libraries or third-party dependencies?)

[DovydasNavickas]

Just as I pointed in #19, I think this functionality shouldn't be our primary concern. What we can do is consider whether it's viable at all and are there any considerations, just as you pointed out, but I think the main goal should be standardizing TypeScript documentation, ASAP. If so, supporting JavaScript is not fitting into that goal.

[octogonz]

BTW when we chatted with the compiler owners, they cautioned us against fostering an unnecessary tribal boundary between "JavaScript files" and "TypeScript files". What if someone works in TypeScript but also has a lot of legacy JavaScript code that they can't migrate overnight? Should they really have to learn two different doc comment syntaxes (and possibly two different documentation tools), and constantly switch between them depending on which file they're editing? If TSDoc-in-JavaScript was modeled as a set of custom extensions for recording type information, then you could use one tool and syntax to work on both kinds of files.

This is probably out of scope for the first release. And I'm not sure to what extent someone would be authoring lots of new API documentation for their non-migrated files. But it made me think that where possible, the TSDoc design should try to anticipate and provide for this possible direction.

[octogonz]

@typhonrt FYI

[IllusionMH]

As I see TSDoc-in-JS this is out of scope of initial release but may be considered later.

Another pain point in JS files that can be addressed by upcoming standard - standardized way to write docs for function overloads. I've tried couple of examples for JSDoc, but non of them provided any meaningful info in VS Code or WebStorm editors.

Even if project can't migrate to TS at some point, but TS LanguageService will handle comments with overrides - devs will benefit from it.

And at would be great to have same doc generator that will be able to process both JS and TS files as well as unify format of comments which will be used across project.

[octogonz]

@mike-north pointed me to this listing of JSDoc tags that are supported by the TypeScript compiler for type analysis:

https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript

We should definitely include these in TSDoc's standard set of tags.

[DanielRosenwasser]

Hey all, @sandersn will be able to help out if you have any questions about supported tags and behaviors.

[hildjj]

What is the current thinking on this issue? I keep running into edge cases where I can express type information in a JSDoc comment (e.g. @param {someType} foo), and using tsc's JSDoc-inJS feature, it works great for typechecking.... but JSDoc's notion of types is completely different, so I can't generate documentation for my project without jumping through hoops.

For example, tuples are easy to describe in a TypeScript type (e.g. [string, number], but impossible to describe in JSDoc.

I'd like to do away with JSDoc in my project, and replace it with something that was coordinated with tsc's type system.