Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

.js files are still run through erb filter without .erb extension #2394

joeytheman opened this Issue Aug 1, 2011 · 16 comments


None yet

Wasn't sure if this was intentional but if you remove the erb extension from a views/view/*.js.erb file, the ruby code is still evaluated when the js file is rendered.


tenderlove commented Aug 1, 2011

@josh is this expected?


spastorino commented Aug 1, 2011

Can you provide a test or an app which shows the issue?


bcardarella commented Aug 1, 2011

@spastorino Really? It takes two seconds to reproduce. @joeytheman gave pretty clear steps on this.


spastorino commented Aug 1, 2011

@bcardarella we have to reproduce every issue in order to fix them. Actually we have 278 open issues and 101 open pull requests, even the most silly issue takes time to reproduce. Help is appretiated ;)


bcardarella commented Aug 1, 2011

Yeah I get that, it's overwhelming. It seemed faster to just reproduce the error with the steps outlined than another method in this particular case.


jackdempsey commented Aug 1, 2011

FWIW, I just tried this in a 3.1.0.rc4 app where I needed a helper for some JS. Worked when it had .erb extension, got this when I removed it:

throw Error("ExecJS::ProgramError: Error: Parse error on line 1: Unexpected 'COMPARE'\n (in /Users/jack/zomg/app/assets/javascripts/something/main.js.coffee

where line 1 is
<% extend ApplicationHelper %>

Here is the app with steps to reproduce the behavior in the readme.



josh commented Aug 2, 2011

views/view/*.js.erb has nothing to do with sprockets. Thats AP view logic.


tenderlove commented Aug 26, 2011

@josevalim can you look at this?

@ghost ghost assigned josevalim Aug 26, 2011


lsylvester commented Aug 27, 2011

It looks like it is defaulting to erb because there is no js template handler has been registered. see https://github.com/rails/rails/blob/master/actionpack/lib/action_view/template/handlers.rb#L45


josevalim commented Aug 27, 2011

So, I don't believe this is a regression. No template handler was given in the filename above which makes Rails default to ERB. We can fix this issue in three steps:

  1. Provide a "raw" or "plain" template handler
  2. Next, we could check in the resolver wether a template handler was given in the filename and if not, raise a deprecation warning saying something like: "the file X did not specify a template handler. change it to ERB in case it has ERB content or use RAW/PLAIN if not"
  3. Then, in the future Rails releases, we can make the default template handler raw/plain. Which is probably a better default anyway.

guilleiguaran commented Aug 28, 2011

@josevalim do you think this is a blocker for 3.1 release and the steps need to be done a.s.a.p or the milestone of this issue can be changed to 3.1.1 or 3.2?


tenderlove commented Aug 28, 2011

@guilleiguaran no, this isn't a blocker, so I've cleared the milestone.

I'm trying to contribute a bit to Rails. Is this still unresolved? Shall I give it a go?


masterkain commented Jan 26, 2012

I tried this yesterday on Rails 3.2.0, I had some odd results.

Using jQuery get from my view I tried to call a controller method that should return a js script to be executed.

View names:

  • action.js.erb: works
  • action.js: renders the entire layout even if the format requested is JS
  • action.js.coffee: if you have execjs+node installed and this view is printing large data, node will consume 100% cpu and never terminate the request.

isaacsanders commented May 4, 2012

Is this still an issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment