sprockets-rails v3 support

[rmm5t]

Asset precompilation and asset dependency behavior is going to change in sprockets-rails v3.

See rails/sprockets-rails#191

Opening this as a placeholder and reminder for when that's all hashed out.

This dependency will be required for future Rails v5 support

[aried3r]

Any news on this, since sprockets-rails v3 is out?

[rmm5t]

Sorry, no news. It would be super awesome if someone had the time to investigate this further.

[why-el]

@rmm5t the issue you link to is closed. Does that resolve it all? Because this issue is blocking #159.

[rmm5t]

the issue you link to is closed. Does that resolve it all? Because this issue is blocking #159.

@why-el Unfortunately, no. If you look at the Travis-CI build, we're still failing against the rails master branch. However, I think our current problem might be with changes in the latest sass-rails.

[why-el]

Yes, sass-rails is pushing for the latest Sprockets. Perhaps you can fix sass-rails to the version still using Sprockets v3?

[rmm5t]

Perhaps you can fix sass-rails to the version still using Sprockets v3?

Perhaps, but heavily restricting dependencies like that increases the likelihood of dependency hell for everyone later. Plus, I'd like to maintain complete backwards compatibility with all currently supported Rails versions (e.g. 4.2). To many gemspec version restrictions makes that more difficult.

[rmm5t]

With all that said, pull-requests that keep the current build green and pass against rails master are very, very much welcome. I spent a rushed ~20 minutes on this problem a couple weeks ago, but didn't get to a full resolution.

[why-el]

Yes, completely agree. Would a <= v3 do it? I guess that satisfies the backward compatibility requirement and solves this issue. I can either leave a note in #159 for this or submit a PR that has both #159 and my change to fix this issue.

[rmm5t]

Would a <= v3 do it? I guess that satisfies the backward compatibility requirement and solves this issue. I can either leave a note in #159 for this or submit a PR that has both #159 and my change to fix this issue.

I think we're talking more along the lines of a sprockets restriction like < 4.0.

Also, just to clarify, a PR only helps if time is also spent in going through and making sure that everything runs green against all the gemfile permutations (specified in .travis.yml and gemfiles/*.gemfile). If it's just a version lock against sprockets, great, but that needs to be verified.

[rmm5t]

Actually, I just relaxed the versions in the rails-master.gemfile, and I have a passing build there now. Sanity checking. Might be able to get this sooner than expected.

[rmm5t]

Closed by 100f9d7

[rmm5t]

@why-el Thanks for the nudge. I think we're good now. I'll get a new release out once all automated builds verify as green.

[why-el]

Fabulous, thank you for the prompt response.

On Tuesday, February 9, 2016, Ryan McGeary notifications@github.com wrote:

@why-el https://github.com/why-el Thanks for the nudge. I think we're
good now. I'll get a new release out once all automated builds verify as
green.

—
Reply to this email directly or view it on GitHub
#125 (comment)
.

Wael Khobalatte

[rmm5t]

v4.5.0.1 is now on rubygems