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

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?)

[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.

[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.