My idea is to only change Renderer.renderDefinitions/Renderer.renderStatements such that the @nocollapse comment is added there, if annotateForClosureCompiler is enabled. This is similar to ngtsc's approach of adding the comment in a TypeScript transformer, which would be the renderer in ngcc's case.

Thanks for the quick feedback @JoostK!
How are you imagining that transform to happen? The renderer just calls

this.srcFormatter.printStatement(stmt, sourceFile, imports);

Which goes all the way from Statement (which you are wanting to not change) to string. It could be possible to just prepend the @nocollapse to the string, but that seems hacky at best.
So should we just figure out which type of stmt need these added in the renderer?
To make it that Statement supports leading comments would still require these changes in ExpressionTranslatorVisitor, and I'm afraid that by the time we get to printing it is much more ambiguous which statements even need the @nocollapse annotation. At the very best we would have to do something like

if (this.annotateForClosureCompiler && stmt.expr instanceof WritePropExpr && someEsotericCheckThatThisIsAStaticPropertyAndNotAnyOtherKind(stmt)) {
    stmt.expr.leadingComment = '* @nocollapse ';
}
this.srcFormatter.printStatement(stmt, sourceFile, imports);

Which still requires the changes in WritePropExpr and visitWritePropExpr.

While writing the above I tried implementing it and was unsuccessful. I'm happy to be convinced that there is a better way, I'm just not sure I'm knowledgeable enough already to be able to implement that way.
I'm happy to collaborate on this PR with commits authored by others.

Thanks for the reply. I agree that tacking on the comment to a string would be a hack, but I see some other ways:

1. Emit a o.CommentStmt in front of a definition statement in createAssignmentStatement (would need to start returning an array). This would require updating ExpressionTranslatorVisitor as support for that statement kind is not currently implemented.

2. Introduce a new type in ngcc to represent a statement, which can have comments associated with it. RendererFormatter.printStatement can then take this new type and emit synthetic comments as desired. Something like this:

export type EmitStatement {
  stmt: o.Statement;
  comments: string[];
}

_{I'm not sold on the name but I can't think of something better}

3. Change RendererFormatter.printStatement such that it accepts the leadingComment you added to WritePropExpr. The implementations can then add the comment synthetically to the ts.Node before printing it as a string.
   _{This is still a bit of a hack.}

My personal preference would be in the order as presented above. If you run into problems feel free to follow up here.

I should be able to get to this toward the end of next week.

@DavidANeil - do you still have time to work on this?

Yup sorry for the radio silence, my plan was to come back to it as soon as I enabled Ivy for our code base, and I thought that "the end of next week" would be a good estimate for when that would be done, but it turns out "the end of next month" was probably a more accurate estimate. I think I am about 3/4 done with enabling Ivy, so I should be circling back to this in a week or so?

Sorry I can't get to it sooner.

No problem. Good luck with your ivy-ifying of your code.

Let's discuss the overall "Angular + Closure Compiler outside of google3" story before we start adding more flags and closure support into ngc and especially ngcc.

I have a meeting with @DavidANeil scheduled for next week, so I'll bring up this PR there and will post an update on this PR afterwards.

Sounds good, that's what I was thinking too.

I just wanted to get this PR into a better state before I entirely forgot my mental model of the ngcc renderer.

Presubmit

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}