Question

What happens to comments in a minified JavaScript file? How can the browser know when the end of the comment is when everything is condensed to one line? Take this little example, I have Google tracking code like this:

//Google tracking
var _gaq = _gaq || []; 
_gaq.push(['_setAccount', '123456']); 

The minified version pulls everything into one line

// Google tracking var _gaq = _gaq || []; _gaq.push(['_setAccount', '123456']);

There are more statements, but when I examine the JavaScript code in an editor, it looks like one giant comment (more or less). Is there a hidden character that tells the browser when to end a comment or is this code just not being executed?

Answer 1

Minifiers strip comments or insert line-breaks. For example, Closure Compiler’s FAQ says:

Can I use the Closure Compiler together with other JavaScript minifiers?

Yes. Closure Compiler reads in any valid JavaScript and generates valid JavaScript, so you can apply the Closure Compiler to a JavaScript file either before or after you run the file through a different minifier.

Remember that Closure Compiler and other minifiers might have expectations about the incoming code. A minifier that strips comments may remove licenses or annotation information needed by another tool, for example.

Sometimes you really need a comment in which case they put in a line break.

I have copyright notices or open source license text that must appear in my source code. How do I keep the Closure Compiler from stripping this text out?

Closure Compiler supports the JSDoc @license tag. Add the @license tag to any JSDoc comment to preserve the comment in the compiler output. See Annotating JavaScript for the Closure Compiler for more information.

Minifiers also tend to break lines occasionally, because some interpreter’s source code parsers crashed or performed really slowly on really long lines.

https://bugzilla.mozilla.org/show_bug.cgi?id=634444

Previously, because we were dealing with chunks, there was a limit to how much of a line an error message could include. But now the error message contains the entire line. If you have very long lines and lots of errors, it’s a recipe for high memory usage, especially since we call js_DeflateString() on the error message string, resulting in two copies of it (one made of jschars, the other made of chars).

On the site in question, heaps of errors occurred on a line containing 122,895 chars, resulting in over 1G of chars (at 3 bytes per char!) being put into error messages.