Remove the nasty spaces left by closure compiler

[xem]

Hello,
Google closure compiler has a "bug" (I guess) where it randomly inserts spaces in the minified code it outputs. Exemple with my last js1k entry:

google CC output:

g||(d=e=h=k=o=n=p=l=m=0,b.style.background="#112233",g=f="030000300330221211300303212222122121111211212112111000003112122033333303003033030330333222221121030000".split(""),document.write("<center><input type=range style=width:6em oninput=k=value/5-9><input type=color value=#112233 oninput=b.style.background=value><input type=color value=#ffffff id=j><p><button onclick=p=1==d?q-p:q;h=1;d=1;e=1>X<button onclick=p=1==d?q-p:q;h=1;d=1;e=3>-X<button onclick=p=2==d?q-p:q;h=1;d=2;e=1>Y<button onclick=p=2==d?q-p:q;h=1;d=2;e=3>-Y<button onclick=p=3==d?q-p:q;h=1;d=3;e=1>Z<button onclick=p=3==d?q-p:q;h=1;d=3;e=3>-Z</button><p><button onclick=h=1-h>pause<button onclick=if(q<2048)p*=2,q*=2>slow<button onclick=if(4<q)p/=2,q/=2>fast"), q=256,onmousemove=function(r){l=(a.width-2*r.pageX)/50;m=(350-2*r.pageY)/30;n=1});n&&o++;h&&(p=(p+q-1)%q);a.width+=0; for(i=f.length;i-=3;)x=+f[i],y=+f[i+1],z=+f[i+2],u=2>x?1:2,v=2>y?1:2,w=2>z?1:2,170>o?(x=30>o?1.5+(30>i?.01:0):50>o?1.5+(u-1.5)*(o-30)/20:150>o?u:u+(x-u)*(o-150)/20,y=70>o?1.5:90>o?1.5+(v-1.5)*(o-70)/20:150>o?v:v+(y-v)*(o-150)/20,z=110>o?1.5:130>o?1.5+(w-1.5)*(o-110)/20:150>o?w:w+(z-w)*(o-150)/20):(t=([x,x,y,z][d]+e)%4,u=2>x?[0,1,1,0][t]:3-[0,1,1,0][t],v=2>y?[0,1,1,0][t]:3-[0,1,1,0][t],w=2>z?[0,1,1,0][t]:3-[0,1,1,0][t],1==d&&(u=t),2==d&&(v=t),3==d&&(w=t),x+=(u-x)*p/q,y+=(v-y)*p/q,z+=(w-z)*p/q),c.lineTo(a.width/ 2-100+60*x-(x-1.5)*(z-1.5)*(k+9)+l*(z-1.5),80+60*y-(y-1.5)*(z-1.5)*(k+9)+m*(z-1.5));c.lineWidth=99>o?35-o/3:2;c.lineCap=c.lineJoin="round";c.strokeStyle=j.value;c.stroke();setTimeout(_,30)

this code contains 3 unnecessary spaces: , q=256, ; for(i=f.length, a.width/ 2

I submitted an issue to google CC about that but they don't seem to care.

But maybe you can do the fix in regpack!

I'd love to see RegPack automatically remove obvious unnecessary spaces (before or after a comma, slash, semicolon, etc.)

It would save bytes, and it would save a lot of valuable time for the people trying to remove those spaces by hand everytime they pack their code.

cheers!

cc.@subzey

PS: I know, there are other JS minifiers than CC, but it's generally the best one and the most used. That's why I ask :)

[subzey]

My 2 cents: As for me, every tool should stick to UNIX-way: “Do One Thing and Do It Well”.

What if one needs that whitespace for some obscure reason? Say, _ is also used as a seed for some PRNG (@p01 often does something similar, if I remember correctly) and this byte can be “sacrificed” making demo look much nicer.

[xem]

Sure, spaces can be useful in some crazy experiments, but for regular compression, they are annoying, especially when they come from closure compiler for no apparent reason

[Siorki]

This is clearly a workaround for a bug from another tool. If you are really concerned with size (such as for js1k), I would recommend hand minification over Closure Compiler, although the latter could be a good starting point.

I was considering the possibility to add a minification stage first, with a different workflow in mind : when hand minifying, I try to keep the code as readable as one can do (comment, spaces, indents. See the "human readable" code from my js1k entry Voyager ), then run it through minification (not CC) then RegPack before submitting.

Adding an optional minification stage would make the workflow simpler. It would also solve your issue by removing the unnecessary spaces added by CC.

[keithclark]

I know this is and old issue but, I was looking at closure compiler docs the other day and stumbled over an FAQ that explains why the whitespace is there:

The Closure Compiler intentionally adds line breaks every 500 characters or so. Firewalls and proxies sometimes corrupt or ignore large JavaScript files with very long lines. Adding line breaks every 500 characters prevents this problem. Removing the line breaks has no effect on a script's semantics. The impact on code size is small, and the Compiler optimizes line break placement so that the code size penalty is even smaller when files are gzipped.