Emit comments even if related code is not emitted

[zzm2q]

for example:

class A {
  /**
   *  some document
   */
  prop:number;
  constructor(prop:number) {
  }
}

the document part would be removed unless prop initialized with a value after compiled, i think it should be remained in compiled file.

[DanielRosenwasser]

I'm sorry, do you mean that the comment preceding prop isn't being emitted but should be?

[basarat]

@zzm2q just FYI the following

class A {
  prop:number;
  constructor(prop:number) {
  }
}

is not the same as (perhaps what you want):

class A {
  constructor(public prop:number) {
  }
}

[mhegazy]

Also note that the field declaration does not have a JavaScript equivalent; do this is a pure typescript construct that does not get translated. The comment in your example is attached to the field declaration.

[zzm2q]

em, i guess i didn't described clearly.
@DanielRosenwasser yeah, i mean that the comment preceding prop isn't being emitted but should be.

[zzm2q]

There are tow way to walk around it:

class A {
  /**
   * comment would be emitted with first case.
   */
  prop:number = 0; // 1. initialized with a value
  constructor(prop:number) {
    /**
     * 2. comment here also works.
     */
    this.prop = prop;
  }
}

that's ok but not convenient and not obvious。

[danquirk]

Do you want the comment preserved even though the field isn't emitted? The field is not emitted without an initializer (by design) and so neither is its comment.

[zzm2q]

Yeah, that's what i want, it's not strong demand. I want this since i was using jsduck to generate document of my library from ts files but fail to. And then, i successfully generated from compiled js but lost some that comments of property without an initializer.

[mhegazy]

the correct fix here is to allow an extensiblity layer in the emitter and allow such customization if/when needed. #5595 tracks moving the emitter to a transformation based pipeline, and that should get us most of the way to enabling such scenarios. the OP however is out of scope of the TypeScript project.

[cardiffman]

I'm trying to get a "//EOL" comment between declarations at the top level of a file to be preserved. When I researched the necessary option for preserving comments, I was surprised to see that the compiler is configured to preserve comments by default, and you have to ask for comments to be removed. So what I see in the documentation is that comments are 100% supposed to be preserved. The option is not defined as "remove the comments we didn't already remove".

The project I'm considering TS for has an "include" file system which adds in additional files. The system has a handful of different implementations depending on whether scripts come from the filesystem (in one of two different layouts) or from a database. The early version of the database was prone to appending small amounts of trash characters, so we arrived at putting "//EOL" in the file at the end. Then we started using that like the "if name == 'main'" idiom of Python to put a unit test in the file. With the "//EOL" in between, the file would work as a main file when the EOL was ignored. So now we have dozens of files like this. If comments were truly preserved, then the activation energy I would need to transition the project to TS would be much lower, because I could do one file this week, 10 files next week, advertise the benefits, continue converting files lazily until budget was approved. If not, I have to speculate about the benefits achieved based on one or two files, which I manually restore the //EOL in, and then basically get approval to convert the whole thing because I need to plan a big-bang conversion of the include file system up front.