-%> (hyphen character) in .js.erb

Post reply
[image: More message actions]
10:27 PM (1 minute ago)
When I run rake assets:precompile on my app, I get the following
error:

syntax error, unexpected tSTRING_BEG, expecting
keyword_end_erbout.concat
“\n”

which refers to a line in a .js.erb file ending in -%>.

The ending hyphen was added to eliminate the line break in .html.erb
files.
But when I remove the hyphen, the error goes away. The last sentence
ofsection’2.2.1
CSS and ERB’ in
http://guides.rubyonrails.org/asset_pipeline.htmlhttp://guides.rubyonrails.org/asset_pipeline.html
says ‘Note that the closing tag cannot be of the style -%>.’ Does anyone
know why adding the dash before %> in .js.erb (and apparently in
.css.erb)
files causes the rails precompiler to fail?

Thanks!

shellz wrote in post #1095771:

syntax error, unexpected tSTRING_BEG, expecting
keyword_end_erbout.concat
“\n”

which refers to a line in a .js.erb file ending in -%>.

The ending hyphen was added to eliminate the line break in .html.erb
files.
But when I remove the hyphen, the error goes away. The last sentence
ofsection’2.2.1
CSS and ERB’ in

http://guides.rubyonrails.org/asset_pipeline.htmlhttp://guides.rubyonrails.org/asset_pipeline.html

says ‘Note that the closing tag cannot be of the style -%>.’ Does anyone
know why adding the dash before %> in .js.erb (and apparently in
.css.erb)
files causes the rails precompiler to fail?

Because using -%> causes a syntax error, unexpected tSTRING_BEG to
occur.

<<>>

In my quick test case I got a syntax error, unexpected ‘)’
…rbout.concat(( ‘Hello World’ -).to_s); _erbout.concat “”);…

Notice that the dash is still there trying to be concatenated in.

I don’t really know exactly why, but it’s obvious you cannot use -%> in
js.erb or css.erb, so don’t do it and your code wont fail.

See the last sentence of section 2.2.1 of the Asset Pipeline guide:
http://guides.rubyonrails.org/asset_pipeline.html

Sorry, that was redundant.

It’s because -%> needs to know how to remove whitespace from within the
file itself, parsing & reading the content outside the replacement
content. I don’t know for sure but I’ll bet the explanation is simply
that this is too complicated in these pipeline files because whitespace
works differently.