Rails 6.0.2 - image_tag('logo') works in development but crashes in production

Assuming there is an image file in app/assets/images/logo.png

Rails will happily find and generate the correct tag for image_tag('logo') in development mode. However, in production mode (on Heroku, default asset pipeline / webpacker settings), image_tag('logo') will fail with an asset not present in asset pipeline error.

Correct approach is to use image_tag('logo.png') instead. Using image_tag('logo') should break or emit a warning in development.

Googling it reveals I’m not the only person falling afoul of this one:

12 Likes

That really is the definition of WTF in my book, wonder if it’s already on someone’s radar.

1 Like

This has bitten me in every app I’ve written since the asset pipeline was first introduced in Rails. @ferngus you should definitely file an issue for this, I couldn’t find an existing one.

2 Likes

This feels like a small well-defined issue to file!

However, I know that @rafaelfranca is currently doing a lot of things, and so I worry that that issue might not get addressed quickly.

Does anyone reading this (doesn’t need to be OP) have time to work on a PR for this?

What would be your prefered behavior?

It makes sense to me if this breaks in development, with a pointer to use logo.png instead.

I can take a stab at it!

Hi @Betsy,

I actually was investigating the issue at this moment, and the error is due to an inconsistency between manifest and environment resolvers on sprockets-rails.

The thing is though, there were already 2 issues pointing out this issue on the gem’s repo, but since nobody from the rails team said anything, I wonder now if this is by design or if there is another complication involved.

I’m still wanting to attack this one, but would be nice to know if there are any specific reason for these issues not to receive attention.

2 Likes

My best guess would be that Sprockets has always had overburdened maintainers. Sprocket’s original author has long since departed Rails, and the subsequent maintainers haven’t always had a huge amount of time to devote to it.

So I would guess that the issue is as simple as lack of time, and that @rafaelfranca would appreciate you taking the time to attack the problem!

1 Like

Ok, gonna give it a shot and continue the discussion there if necessary, thanks.

2 Likes

Thanks! Was hesitant to file an issue as I’m not familiar with Sprockets’s innards, didn’t know whether this had been raised before under a different guise .