Generation strategy : what is documented vs what is actually exported

[alxroyer]

While working on PR#98 for 'export default' support, I wondered what would be the best strategy:

• generate declarations for everything documented with jsdoc in the input source code?
• or generate declarations from what is actually exported by the module?

My feeling is that it would be better to have tsd-jsdoc be based on what is exported:

• it would fix undesired effects as noticed in issue#99,
• it would avoid exposing symbols in the types.d.ts generated file that the js module does not actually export.
• it could avoid requiring an explicite jsdoc comment on module.exports for the following common export pattern:

exports = module.exports = myExport

issue#96 / PR#98 would be a prerequisite for this kind of evolution.

[englercj]

I'd also prefer that, in previous versions of jsdoc it hasn't been very good at getting "what is exported" correct.

We'd also need to extrapolate from what is exported, other things that should be exported.

For example, consider a function that takes an interface as an arg. The function will be marked as exported, but the interface likely won't be. In the TS definitions, both should be exported.

I'd love to rework the logic to work this way instead, and if you are up for it I'm happy to accept a PR.

[alxroyer]

Sure, I'll try to implement such a backward walk from exports.

Actually, assuming this strategy could help with the handling of exports = module.exports = myExport patterns for issue#96, so I may give it a try in PR#98.