TypeScript: removeComments compiler option seems to be ignored when using typescript 1.5.0-beta

Hi I’m using version 1.8.10 and if you don’t leave a new line between the header and the first line of code the header is not preserved…

Also If you don’t declare a constructor like the one below the header is not preserved in .d.ts files. constructor(public el:ElementRef) { console.log(‘constructor’, el); }

@magemello the whitespace does indeed seem to be a problem. I’ll look into it.

There are a lot of things being conflated here. Let’s run down the list of special constructs that TS knows about:

1. ‘Detached’ comments. These are at the start of the file or function and must have at least one blank line between them and the next construct.
2. ‘Directive’ comments. These start with /// < and have some well know name after the open angle (like reference or amd-module.
3. ‘Pinned’ comments. i.e. comments that start with /*!.
4. ‘Normal’ comments. i.e. any other type of comment (these start with /* or //).

Currently, thanks to the work by @yuit, --removeComments should only affect the last comment type. In other words, the presence of this flag only affects if we emit ‘Normal’ comments. These are the general comments that make up the majority of comments in a project, and which add the most to output size. They also have no meaning except to the developer, and thus can be removed safely, and have no meaning to other tools.

Currently --removeComments does not remove the first three comment types, and we will attempt to preserve them regardless of this flag. These reason for this is as follows:

1. ‘Detached’ comments often indicate a copyright declaration of some sort. Developers often want these transferred over, even if they don’t want regular comments. So we’re keeping those by default.
2. ‘Directive’ comments are important to some customers. We have customers who use reference directive in later parts of their JS processing pipeline. So we’re also keeping those by default.
3. ‘Pinned’ comments literally exist to tell tooling ‘do not remove me’, so we should always keep these no matter what**.

Now, we recognize that some users may want further comment removal. Specifically removal of ‘Detached’ or ‘Directive’ comments (again, we will always try to preserve ‘Pinned’ comments**). When @yuit did this work we discussed this need and speculated that we would have further options to the compiler to allow customization here. We’ll be keeping the --removeComments flag and keeping the new default behavior. However, we are also considering adding things like (final name/form TBD):

removeSpecialComments=detached,directive

With such an option you can opt out of our default behavior and trim your files even further. We did not do this originally because we weren’t even certain there would be anyone who would want/need this. And investing in this work based on speculative need seemed unnecessary. Now that it’s clearer that there are some people who might want this, we will revisit and potentially reconsider this decision.

** Currently pinned comments are not emitted in some cases. However, i consider that a bug. We should always be emitting pinned comments in all circumstances. That’s the point of the construct in the first place. Fortunately, this bug doesn’t seem to have that much impact. The places where people use pinned comments do not seem to the be the same as the places where we accidentally do not emit them.

Another (possibly related) bug: multiline comments are always removed if they are the only thing in thing in the body of a function:

tsconfig.json

{
    "compilerOptions": {
        "module": "commonjs",
        "removeComments": false
    }
}

index.ts

function foo() { /*
    This multiline string will only work
    if the TS compiler does not remove comments.
*/ }

λ tsc -v
message TS6029: Version 1.5.3
λ tsc -p .

Generated index.js

function foo() {
}

If I add a statement to the body of foo, then I do not see this problem.

This breaks code that uses the multiline module.