3.4.1: Relative assets urls are converted into absolute ones. Breaking existing code.

[tvdeyen]

In 05dbab2 a breaking change was introduced and released as 3.4.1 as a hotfix for the already breaking 3.4.0

Before sprockets 3.3.0 a url like url(img/thing.gif) inside a folder loads the image from the current folder (the folder the file lives in) relatively. This is valid HTML/CSS and every css processor reads this correctly.

Now the url is converted into an absolute URL. This breaks a lot of existing frontend code. In a patch level release by the way.

Can we revert this please and release a new version? Then rethink changes made in 3.3.0 and 3.4.0 and release them as a 4.0 instead if a breaking change is intentional/necessary?

[tvdeyen]

You can see the breakage in this failing CI https://github.com/AlchemyCMS/alchemy_cms/runs/4300052710?check_suite_focus=true#step:12:127

and what was necessary to fix it

https://github.com/AlchemyCMS/alchemy_cms/pull/2218/files

as you can also see we have to use a relative url starting from the top most folder (the sprockets lookup path) but it is then turned into an absolute url.

Both behaviors seem wrong from what a browser (and a file system) would usually do.

Expected behavior:

url("img/some.gif")

from a file in a folder app/assets/stylesheets/components/style.css

should return a url

url("/assets/components/img/some.gif")

and not

url("/assets/img/some.gif")

while a

url("/img/some.gif")

should return

url("/assets/img/some.gif")

[rafaelfranca]

@jcoyne can you take a look on this one as well please? We should making the absolute path relative to the current asset, and that should fix the issue.

[jcoyne]

@rafaelfranca yes, I'll take a look today.

[jcoyne]

@tvdeyen is this still an issue after #485?

[nickcoyne]

I see this issue in versions 3.3.0, 3.4.0 and 3.4.1. No problems on 3.2.2.

[jcoyne]

@nickcoyne the code from #485 hasn't yet been released, but it is in the main branch.

[nickcoyne]

ok, thanks @jcoyne, I'll give that a try then.

[valscion]

This issue still affects us even with the changes in #485. Previously sprockets-rails output the filenames as relative and now the change to paths being absolute breaks our build.

I don't really understand the reasoning behind this change and why these tests are the expected ones:

sprockets-rails/test/test_asset_url_processor.rb

Lines 52 to 63 in 4e0f168

	def test_relative
	input = { environment: @env, data: 'background: url(./logo.png);', filename: 'url2.css', metadata: {} }
	output = Sprockets::Rails::AssetUrlProcessor.call(input)
	assert_equal("background: url(/logo-#{@logo_digest}.png);", output[:data])
	end
	def test_subdirectory
	input = { environment: @env, data: "background: url('jquery/jquery.js');", filename: 'url2.css', metadata: {} }
	output = Sprockets::Rails::AssetUrlProcessor.call(input)
	jquery_digest = 'c6910e1db4a5ed4905be728ab786471e81565f4a9d544734b199f3790de9f9a3'
	assert_equal("background: url(/jquery/jquery-#{jquery_digest}.js);", output[:data])
	end

Is there any way to make sprockets-rails still output the paths as relative like it used to do before v3.3.0? Our asset pipeline relied on sprockets-rails outputting the relative paths and the change in v3.3.0 seems to have made that impossible.

[jcoyne]

@valscion This is all driven by the new Rails 7 asset pipeline, which primarily uses sprockets-rails as a post-processor for cssbundling-rails. It was the fix for rails/cssbundling-rails#22

Your knowledge of sprockets-rails and it's traditional uses likely exceeds my own, so your help with this issue would be welcome.

It seems that AlchemyCMS may be an outlier in terms of how sprocket-rails is used since you have images in a subdirectory of app/assets/stylesheets. I'm still trying to wrap my head around this usage.

[jcoyne]

@rafaelfranca I'm way out of my depth here. I've looked but I'm not sure how to go about this.

[valscion]

Ok well good to know that this is driven by Rails 7 needs 👍. We'll pin our version to 3.2.2 as this backwards-incompatible change was released in v3.3.0 ☺️

[tvdeyen]

We'll pin our version to 3.2.2 as this backwards-incompatible change was released in v3.3.0 ☺️

As I asked above, can we bump the version to 4.0.0.pre with the changes for Rails 7 and revert the breaking changes from 3.3, 3.4 and release them as 3.3.1 and 3.4.2?

Then we can pin our projects to sprockets-rails ["~> 3.3", "< 4.0"] and Rails 7 can start using 4.0.0pre

@rafaelfranca @dhh are you fine with that?

[jcoyne]

@tvdeyen We use cssbundling-rails + sprockets-rails on a rails 6.1 app, so that might cause a breaking change for us. It could work if the dependencies didn't exclude rails 6.1. However, I don't think that this breakage was supposed to happen in rails 7. This is a bug that needs to be resolved for all users of this gem.

[tvdeyen]

@jcoyne could you use proposed 4.0.0.pre in your Rails 6.1 as well? I am not saying that sprockets-rails 4.0 should only work with Rails 7, but that Rails 7 uses sprockets-rails 4 as default if the breaking changes are necessary for Rails 7.