-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Fix bug: keep comments unless --removeComments #7213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This is a straightforward fix for bug microsoft#2546. Keeps most or all TS comments in the output, unless the option --removeComments is enabled.
Hi @staltz, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! TTYL, MSBOT; |
// Ambient class | ||
// Ambient enum | ||
// Ambient enum with integer literal initializer | ||
// Ambient enum members are always exported with or without export keyword |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This output is undesirable because it's extremely misleading. There's a reason we don't emit every comment, and this is the typical example of why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we define what are precisely the conditions to hide or show comments?
Honestly, that's the hard part (if we had a good rule, we would have done it already). Clearly leading comments for type declarations shouldn't be present in the emit as they look like misleading nonsense, but comments between an opening brace of a statement block and another expression statement should be present.
Figuring out where it makes sense to emit the comments and where it doesn't is the hard part. Simply emitting every comment isn't the right fix.
Thanks for sending this out @staltz, but since this isn't the correct approach, I'm going to close this PR. Feel free to follow up with a new one though. |
I'm not going to submit a new PR until there is a clear notion of what #2546 actually means and what is the acceptance criteria. It serves us (RxJS project) a real purpose: being able to keep JSDoc-style comments ( |
Is it really a transpiler's business to decide which comments have value? Transpilers can't read. Seems strange. IMO, this should be "all in" or "all out" barring comments that take some standard convention that signifies something you don't want removed to contain, say, a license or copyright. There is prior art for that. |
May we have a flag to keep ALL comments, if we really want it? |
Fixes #2546.
This is a straightforward fix for bug #2546. Keeps most or all TS comments
in the output, unless the option --removeComments is enabled.
(CLA signed, DocuSign Envelope ID: 2F26CC42-D7EE-48C6-B680-A6C0E3F7E58F)