Automatic asset paths prevent logical asset organization

rubyonrails-core
1

Hey Andrew,

I have always liked the automatic asset paths and thought they allowed the top level Rails applications as well as engine authors the ability to create namespaces via directories.

I read your whole email but kind of got lost. Is your main issue that creating a namespace via directories is a chore since it has to be done in 3 places?

Or a more concrete question. I am the author of the less-rails and the matching less-rails-bootstrap gems. I was very conscious about directory namespaces and made sure that my namespace for less-rails-bootstrap was "twitter/bootstrap". I am a firm believer that engines that deliver assets should follow this pattern. So the question, what would you suggest doing differently vs this setup?

https://github.com/metaskills/less-rails-bootstrap/tree/master/vendor/assets

- Ken

2

Thanks Ken, I’ll try to be more clear:

Asset gems often exist just to isolate those resources into a simple package to save everyone the trouble of reorganizing third-party files specially for the asset pipeline & maintaining that reorganization going forward. For some things the reorganization makes sense, and I won’t disagree with the way you’ve packaged the less-bootstrap gem. +1 for namespacing under “twitter/bootstrap”, but this isn’t necessarily about that.

The issue is that for drop-in use of third-party assets (from plain folders, not gems), I think it’s more logical to keep their files in one self-contained folder and namespace, without having to tease out and reorganize them. As a benefit, we can use a git submodule to update their whole package, and encapsulate access into it using manifest files.

I think I’ll end up settling on something like this:

vendor/assets/images/ # empty

vendor/assets/javascripts/ # empty

vendor/assets/stylesheets/ # empty

vendor/assets/packages/xyz/

vendor/assets/packages/xyz/random.js

vendor/assets/packages/xyz.js # manifest //= ./xyz/random.js

Using “packages” is there to nest everything one level down so I can isolate the “xyz” package into its own directory.

There doesn’t seem to be any documentation or conventions for this so I wanted to open the discussion around how third-party assets should be handled for drop-in use.

My original point was that adding another folder of my own naming e.g. “assets/xyz” would shadow the standard folders: I don’t think that’s desired behaviour. I did update docrails to reflect how it currently works, but let’s discuss if the docs were originally right and Rails currently isn’t: https://github.com/lifo/docrails/commit/ad088f09

So, to be more concrete:

  1. Should asset paths be limited to (images|javascripts|stylesheets) instead of * glob to prevent accidental shadowing? (Other asset paths can be added explicitly.)

  2. If assets/* should remain, should Guides document how other directories in there are meant to be used? (e.g. just for adding extra file types like “flash”)

  3. Promote something like “vendor/assets/packages” as an optional convention, or bless it as a standard path for drop-in use of asset folders?

Andrew