Closed lilith closed 10 years ago
Thanks for the report. I suspect there was an issue in compressing your particular javascript. Can you do a little research to rule that out, or post the JavaScript you're trying to compress?
Oh, it's very likely a javascript bug - I just thought I remembered the error handling being different under 1.9.3. I had some trouble reproducing it locally since I couldn't get a detailed ruby error on the server.
Is there a way I can get the syntax error message from within the RuntimeException object?
I'm having this issue with 1.9.3, so it's not related to 2.0
Yeah - turns out YUI Compressor broke backwards compatibility somehow. A particular version of highlight.pack.js was at fault, but had previously worked fine.
Thanks for a tip, Nathanael.
I locked yui-compressor version in gemfile like this: gem 'yui-compressor', '~> 0.11.0'
and it seems to be working for me.
In the yui-compressor gem v0.12.0, we upgraded from YUI Compressor 2.4.7 to 2.4.8. Are you thinking there was a regression in YUI Compressor 2.4.8? I'd like to see an example of a file that exhibits this problem. If anyone can point me to such a file, I'd be happy to have a look.
As a side note, many people use this gem by first concatenating many JavaScript files into one stream before passing them off to YUI Compressor. In this typical case, even if YUI Compressor could give you more details, it's already too late if you want to be pointed to the original source file with the problem. I recommend using something like https://github.com/jshint/jshint or https://github.com/douglascrockford/JSLint if possible to identify errors before compression.
@stevecrozz I've sent you a file.
Mine is http://imageresizing.net/js/highlight/highlight.pack.js As far as I can tell, JSLint just complains about an missing implicit semicolon. I really don't care too much; I was incorrectly re-compressing pre-compressed javascript anyway - fixing that avoided the problem.
Easier error logging/debugging would be great - I was originally confused into believing it was a 1.9.3/2.0.0 bug since that was the 'only' change (other than updating this gem). Seeing the error as a SyntaxError instead of RuntimeError would probably have been enough to clarify.
nathanieljones: Your issue underlying problem seems to be caused by using the keyword let
as an object property name in highlight.pack.js. For example, var i = {let:1};
compresses fine with YUI Compressor 2.4.7 but not 2.4.8. Interestingly, this is allowed under ES5, but support for it isn't universal among browser vendors (http://kangax.github.io/es5-compat-table/#Reserved_words_as_property_names). Regardless, it does seem like a YUICompressor bug, so it should probably be reported upstream.
skatkov: Your issue is from this use of IE conditional comments which you're using for browser detection. Here's an example of script that compiles in YUI Compressor 2.4.7 but not 2.4.8. function () { /*@cc_on*/ return; }
This looks like perfectly valid JavaScript to me and so I think this is also a YUICompressor bug that should be raised with the YUI Compressor project.
Maybe we can submit these failing test cases upstream.
As far as this project goes, I tried increasing the verbosity level in the call to YUI Compressor and the extra output was not helpful, so we probably shouldn't do that. Since the command runs in a separate java process, there's not much else we can do besides check the exit status and raise a generic exception if the status is non-zero. But I'm open to suggestions if there are any.