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.

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.

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)

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.

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

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

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

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.

@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!

I'd suggest
comments: "never" = no comments
comments: "declaration" = comments are put into the .d.ts files
comments: "emit" = comments are put into emitted js files

hope can have this,
i don't think we should use another tool when we wanna remove comment on .js, but keep it on .d.ts

@DanielRosenwasser to answer your question:
I think there's a difference between comments used for development and comments used for API consumers.

Comments for development (Starting with // or JSDoc with @internal) live only in the source code and are to help make future development easier. These comments do not need to be in the distribution files as they are of no use for the consumer.

Comments for API consumers (JSDoc) should live either in the declaration d.ts file or in the compiled distribution files. These comments provide explanations of functions, parameters and other things a consumer of the API can use.

My ideal situation:

• Regular comments used for development and JSDocs with @internal are not outputted to the disctribution files.
• The docstring or JSDoc is outputted to the d.ts file.
• The docstring or JSDoc is optionally outputted to the .js file.

Since VSCode looks at the d.ts files for documentation, emitting the JSDoc to d.ts files should have priority over the .js files.

This could use the tsconfig suggestion @championswimmer made.

I was looking at releasing a typescript library and was really surprised when my comments were either being stripped altogether or completely left in. Having intellisense would be really helpful to end users, but a lot of comments just makes the package size larger.

Though, it did help explain why so many of my third party libraries have nice types but no intellisense documentation.

Is there anything we can do as a community to move this forward? I see official comments, but no confirmation about how to resolve. Given that the proposed solutions are bigger (maybe) not backwards-compatible changes, maybe getting buy-in from one of the core team is important before starting work?

Question

Should JSDoc comments be stripped from public APIs of compiled output *.js files?

While I'd be happy with @championswimmer's suggestion, I don't see that as compatible with existing options. Based on one discussion that I've had with some on the TS team, one high priority is keep consistent non confusing compiler options. Therefore I'm betting that adding a comments option alongside the existing boolean removeComments option is a non-starter.

Backwards Compatible Solution

What if removeComments was expanded from boolean to boolean | 'none' | 'code' | 'internal' | 'all'?

if (removeComments === false) removeComments = 'none';
if (removeComments === true) removeComments = 'code';

• none - Preserve all comments
• code - Preserve copyright comments
• internal - Preserve JSDoc and copyright comments
• all - Remove all comments

Alternative

As the removeComments option does not remove /*! comment blocks, we could add an extra option like preserveJSDocComments that would preserve the appropriate comments when removeComments is set to true.

I was going to submit a separate issue, but I believe mine is related. Why can't TypeScript give us docstrings?

HAPPY TWO YEAR ANNIVERSARY.

@RyanCavanaugh (or anyone else at Microsoft): are you going to respond or just 👎 this too?

Looking at recent releases I'm getting tempted to look at Kotlin for JS now. Building and using libraries in with Typescript is still way off from the simplicity and consistency of Java/Maven ecosystem.
Now that MS has control of NPM too, then isn't this an opportunity to bring the JS ecosystem up.

But until then... can we please have this simple feature to retain JSDoc... PLEASE!

hope one day something like this can be merge
#31813

Official TypeScript documentation describes the implementation of JSDoc without mentioning this behavior. I think the implicit behavior should be something such as the solutions described above, but the documentation should explicitly describe the behavior.

I'm sure a pull request (with test-coverage and documentation) wouldn't be rejected by the team - this is one of those "duh, obvious" features no one can really object to.

But to those of you who think this is a slam dunk and why doesn't it "just" get done: I gave it a shot, and about an hour later, all I've managed to do is run the test-suite, ha ha.

The feature itself is probably something like changing the type of removeComments to something like true | false | "preserve-doc-blocks", then testing for that in the condition here - but there are many types of JSDoc nodes, it's not obvious what to do with all of them (esp. the ones on interfaces and other declarations that don't get emitted) and the test-suite needs to be updated, and doesn't seem to have test-coverage for removal of comments in the first place, so that probably needs to be added first, the feature needs documentation, and so on.

Iterating on a codebase of this size and complexity is never quick or easy - there are only so many developers working on this, and I'm sure they have priorities, and yeah, sometimes apparently simple things take more than two years. If you think it's so easy, why don't you do it and submit a PR 😀

Currently, all comments are removed from d.ts when removeComments is false. Am I missing anything?

playground

@Zzzen yes, you are
this is about JSDoc comments specifically

😕 Do you mean normal comments are never preserved by design?

in a declaration file?
of course they are not

So do you have any idea why // interface Foo is removed in .D.TS section? @thealjey

@Zzzen, because "//" is not a valid way for JSDoc to begin.

JSDoc must begin with "/**".

From the JSDoc getting started guide:

Each comment must start with a /** sequence in order to be recognized by the JSDoc parser. Comments beginning with /*, /***, or more than 3 stars will be ignored. This is a feature to allow you to suppress parsing of comment blocks.

Why not just unify the behavior of removeComments? If removeComments is false, preserve all comment in .d.ts and .js, otherwise strip all comment.

There is a way to keep the comments in declaration files only and stripping them from the js files. But it's a little inefficient.

Basically, you'll need two tsconfig files.

1. tsconfig.json: Base tsconfig file
2. tsconfig.nocomments.json, which will have the following content

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "declaration": false,
    "removeComments": true
  },
}

Now, while in development run the base tsconfig file, which will preserve the comments in .d.ts and .js files. But during production, run the base tsconfig file first, then the nocomments one. An example npm scripts could be:-

"scripts": {
  "build": "tsc",
  "build:nocomments": "tsc -p ./tsconfig.nocomments.json",
  "prod": "npm run build && npm run build:nocomments"
},

Running npm run prod, will first generate .d.ts and .js files with comments, then it will generate only .js files without comments since removeComments is set to true and no .d.ts files since declaration: false, thus keeping the same commented .d.ts files.

All thanks to this original post in dev.to.

End 2021 and nothing on this... still embarrassing.

hope this feature

jsdoc @deprecated is removed from d.ts files. but this is a quite important thing.

Is this going to be fixed

So this problem became something big? 😪

I thought I could fix it in 5 minutes of googling

If you are here searching for an answer to this issue, DONT typescript does not support it!