Preserve JSDocs in *.d.ts files when stripping comments

[dotnetprofessional]

Suggestion/Feature

When using the switch removeComments it will strip out all comments including the ones you may consider useful to the end consumer such as JSDocs. I'd like to strip out any internal comments but preserve any JSDocs comments. It seems that an option to preserve comments in types would be sufficient.

Existing functionality

"removeComments": true,
"declaration": true,

removes all comments including those in *.d.ts files.

Suggested functionality

"removeComments": true,
"declaration": true,

I would think by default you'd want to include the JSDocs in your type defs, so this would remove all comments from the code, but retain any comments associated with the types ie JSDocs.

If however, there is a need to remove all comments then an additional switch may be required to serve that purpose:

"removeCommentsIncludingDeclarations": true,
"declaration": true,

Would produce the same result we have today.

[pocesar]

it makes no sense to remove the comments from declaration files, since they are mainly used during development and won't go into production, I was expecting too that removeComments would only remove them from transpiled .js files.

[DanielRosenwasser]

Legitimate question - why is anyone using removeComments? I would assume that you're using a minifier if you actually care about removing comments, but maybe I'm not aware of other scenarios.

[pocesar]

unminified code not for the browser, mainly. split code base into composable components that will later become part of something bigger (but while in dev, useful being on the consumer part of it). comments in JS = not useful. Comments in .d.ts, uber useful.

Shared code (usually interfaces and mapping objects) that are used in both server and browser, and while it's good to have the comments to be kept in the server side, it's a bad idea to have them shared to the client code (such as comments regarding internal structure, database table names, etc)

[patsissons]

Is this still on the horizon? This is a bit of a pain point with respect to my work-around for #21566 when generating declaration files. Fortunately in my case the declaration file is equivalent to the input source file so i can just replace the generated declaration file with a copied and renamed source file in automation.

[HolgerJeromin]

UglifyJS strips all comments but those with @license or @preserve.

[alexsasharegan]

@DanielRosenwasser, I frequently publish byte-size packages using typescript as my only build step. I usually want my code minified, but my comments available in the declarations since they are doc comments. This is a wonderfully simple way for my to publish packages rather than incorporating a bundler with plugins.

[dotnetprofessional]

HAPPY ONE YEAR ANNIVERSERY!!!!!

Its been exactly 1 YEAR today since this was opened. Are we any closer to having this resolved? This doesn't seem to be a lot of work to fix, but given we've had two duplicates since this was opened, it is something people want. I know I'd like to use it on my OSS projects...

[mindplay-dk]

On a related note: if/when this does get fixed, it would be nice to also adjust the .d.ts output slightly, so that there's a space between doc-blocks and declarations. Currently it's all crammed together.

[dotnetprofessional]

@RyanCavanaugh why mark my reply with a thumbs down? I think its quite valid to ask what's going on with a feature that's been 'In Discussion' for over a year. It would have been more helpful to the community to have spent time replying with an actual update, rather than just being rude!