Media assets ignore folder structure

[gaffneyc]

We just upgraded an app to RC7 and ran into the change to asset_pack_path where all assets are now collapsed into a single media directory. We use nested directories to namespace our assets and I find the new behavior surprising and potentially dangerous.

For example, let's say we have two icons that each represent a component or module within our system.

/app/javascripts/images/projects/icon.svg
/app/javascripts/images/users/icon.svg

Webpacker will copy both of these files to media/icon.svg with one overwriting the other. It was previously suggested to rename the images but that violates the conventions we have in our application. Additionally it would create either a junk drawer (every random file in the same directory) situation or a lot of name stuttering (projects/projects-icon.svg).

I believe the default should be to maintain the nesting that folks choose for their applications, allowing us to reference images in a way that matches that nesting and namespacing.

[joelmoss]

I too found this really quite disturbing. Both for the reasons stated above and also because it's such a change with little or no benefit.

[gaffneyc]

#1887 - Original issue that caused the change

[dwightwatson]

I commented on that other issue but glad to see it's not just me. The silent overwriting of assets with the same name is dangerous, and it feels like a less organised way to deal with assets.

[joelmoss]

Now I know it's the "Rails Way" with convention over configuration and all that, which I would usually subscribe to, but the default Webpack config that Webpacker produces is now ways away from what I need in my projects. And this means me having to make more than just changes to the webpacker config.

Yes I know I can edit the config by adding/removing/merging config options, etc. but this is so messy and unwieldy.

I also find that a YAML config AND the actual Webpack config is a conflicting construct.

I've now got to the point where I simply want to create my own Webpack config from scratch, without any external forces making further (unwanted) changes.

But I appreciate the conveniance of the server side support that Webpacker provides out of the box. Things like Rails integration, compilation, and deployment are hugely conveniant.

So right now I'm exploring my own solution that will solve the above issues.

[theJoeBiz]

I like the concept of organizing output files under js/css/media directories, but I agree that the original path should remain intact. This issue has been tripping me up when trying to upgrade to the RC because our project uses image_pack_tag in multiple places and our images are organized into a directory structure. It feels wrong, especially where scalability is concerned, to write: image_pack_tag('logo.png') when an image located at images/common/header/logo.png.

[jakeNiemiec]

@joelmoss I've now got to the point where I simply want to create my own Webpack config from scratch, without any external forces making further (unwanted) changes.

I talked about this in a long, recent mailing list post:

This is why vanilla webpack got so popular. It knows how to be the vehicle without making decisions for you. WebpackER turns what is supposed to be the equivalent of a "Makefile" into yet another "zero-config" framework.

There's the rub, during some crossroads/problem, users will realize that they can cut out the middleman and just write the exact webpack config that they want (it's already generated for them). They don't need to coerce webpackER to output the right config or translate Vue.js README instructions to webpackER compatible instructions.

If you like the idea behind this, go promote the eject PR. If a user has a problem that webpacker wont fix, like #1845, the user will at least have a path to solve it for themselves.