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/stylesheets/ # empty
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:
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”)
Promote something like “vendor/assets/packages” as an optional convention, or bless it as a standard path for drop-in use of asset folders?