-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Always preserve comments with --minify=0
is used
#20121
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
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.
Makes sense to me, because --minify=0
is only used for debugging and not production builds. For a debug builds, adding comments is no burden and can only help.
Maybe worth mentioning that in the changelog and the setting's docs?
I did update the changelog. |
ChangeLog.md
Outdated
@@ -21,6 +21,9 @@ See docs/process.md for more on how version tagging works. | |||
3.1.46 (in development) | |||
----------------------- | |||
- libunwind updated to LLVM 16.0.6. (#20088) | |||
- The `--minify=0` commnad line flag will now preserve comments as well as | |||
whitespace. This means the resulting output can then be run though closure | |||
compiler or some other tool that gives comments semantic meaning. |
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.
compiler or some other tool that gives comments semantic meaning. | |
compiler or some other tool that gives comments semantic meaning (and | |
should have no downside, as `--minify=0` is only used in debug builds anyhow). |
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.
I'm not sure about that though... --minify=0
isn't just for debug builds.. it might be useful in release builds too, if folks want to do their own minification later on the pipeline.
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.
Yeah, maybe you're right. I just think it would be good to explain why we don't think this will inconvenience existing users. So it's either a debug build, or one that the user will minify later anyhow, and either way we aren't hurting anything.
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.
Yeah .. I guess we could say something like.. "which is in keeping the with spirit of minify=0 which is designed for folks who either want to debug their code to perform their own minification". I'm not sure its worth the extra sentence though.
Sounds good. I added a comment with an idea for a further explanation in the changelog. |
This is useful for folks who want to run the closure compiler as an external step, after linking.
eaca395
to
70418c7
Compare
This is useful for folks who want to run the closure compiler as an external step, after linking.
Fixes google-internal issue: https://buganizer.corp.google.com/issues/287520718