Answering some of @mrmrs_ questions about Rails' Asset Pipeline

asset-pipeline.md

I'd like to have an easily modular and configurable build system with proper logs set up. Seems non-trivial. ∞

I'm not totally sure what you have in mind. Can you expand on what you mean by "configurable build system with proper logs"…?

I'd also like visibility into how these includes work and where some of the imported third party stuff actually comes from. ∞

Ah, yes. The Asset Pipeline's load paths situation is a bit of black magic. To my knowledge, there are at least four places a Rails app will look for assets:

1. In gems (e.g. Compass, Breakpoint, etc.). This is the least obvious since the files you want to include don't appear in the folder structure of your project. You simply include them in, say application.css.scss by doing @import 'breakpoint';.
2. In lib/assets. I think. I have no idea what might end up in here, but it's a default folder in a fresh Rails app.
3. In vendor/assets. I believe this is where you would put third-party CSS, JS, etc. (e.g. Normalize.css, jQuery). Libraries, basically.
4. In app/assets. This is where most of your JS and CSS (SCSS, etc.) files will go. You can create as many subfolders as is practical for your project and include them in application.css.scss with lines like @import fonts; (which maps to app/assets/stylesheets/_fonts.scss), @import base/*; (which includes all SCSS files in app/assets/stylesheets/base/), and @import "components/**/*"; (which includes all SCSS files in app/assets/stylesheets/components/ and any of its subfolders).

I'm not certain of the exact load order, so keep that in mind.

In my experience, I've never put a file or seen a file in lib/assets. Also, I rarely ever put files in vendor/assets.

I've recently started using Rails Assets which is this great service that ad hoc creates gems from Bower packages. For me, it's replaced the need to put anything in vendor/assets. Take a peak at lines 4, 12, and 13 in this Gemfile and line 1 in this SCSS file for an example of how I'm using the service to include Normalize.css.

I would also like them to stop promoting the practice of having a new css partial for every view. ∞

Agreed, that shit's terrible. Delete any of those files as soon as they're created by the generators. 🔥 💀

---

Hopefuly some of that is helpful. I'm curious to hear what you have in mind for your first comment.

Thanks a lot for taking the time to write this out!

So npm and gulp has left me pretty spoiled. It's basically what I always wanted and everything else seems horrible now. Small modules I could piece together depending on what my project called for? That is what I call heaven.

So I want to be able to:
Grab any file / partial I need (Rails provides this ability with having a manifest file like application.css.css)
And then run a series of processes against it.

I want it to be trivial to process those partials declared in a manifest file against:

sass, less, rework, postcss, etc

Then have it processed through - autoprefixer / custom functions with postcss
Then linted with csslint (with output spit to the console), minified with any css minifier you choose, and then have the minified css dropped inline to the head.

When the css is minified I want to see logs of minified file size vs unminified file size and then the size of the files after gzip compression.

If you want to see this in practice try grabbing http://github.com/mrmrs/tachyons or http://github.com/mrmrs/mnml and from the root of the project just run npm install && npm start
I think even someone without much javascript agency (like myself) can mix and match these modules
super easily to get whatever desired flow / output you want.

Having this build system be configurable - also allows you to easily write your own functions to process css.
You could integrate all the stuff from cssstats.com into a build step so that your whole css codebase is constantly documented. Or grab things like that stylestats module for log output. The possibilities are endless!

I think my biggest complaint though is with compass and bootstrap being included and how they then include their own partials and it becomes a rats nest I can't figure out how to untangle. Part of this is just my own agency with Rails, but I've worked on a number of rails projects and it seems really non-trivial to implement best front-end practices I already know about.

I totally understand the frustration. The default Rails app generated with rails new foo includes a bunch of stuff that I imagine someone somewhere sees as sensible defaults but for my money, you can 🔥 💀 everything in application.js and application.css.scss. Same goes for most of the gems in Gemfile.

rails new takes some options that might cut back on a lot of the defaults:

rails new foo --skip-javascript --skip-turbolinks

None of that gets to what you really want, though.

Based on what I know about your work and what you've outlined above, it sounds like what you really want is what's outlined in this article you mentioned on Twitter. I haven't tried any of that out yet, so I can't vouch for it, but at first glance it looks to be most of what you described.

At this point, Rails has grown to include quite a lot of stuff. If you're looking for something smaller but still written in Ruby, you may want to look in to Sinatra. You can do all kinds of things with it and its less structured than Rails (a good and a bad thing).

Not trying to convince you to stick with the Asset Pipeline, but doing a little digging I found a couple of things:

• If you published your various modules to Bower, you could include them with Rails Assets as mentioned earlier.
• Autoprefixer for Ruby and Ruby on Rails
• I'm not familiar enough with Rework to know how that might plug in to something like Asset Pipeline.
• I found some sketchy, dated advice on running linters in Rails but… I don't trust them.

So all that's to say, there are some tools out there but it's clear development on the Asset Pipeline hasn't kept up with the breakneck pace of the front-end tooling scene. I've not yet felt the kind of pain you, @jessicard, and others have felt but there's clearly deficiencies in Asset Pipeline. I very well could be suffering from Stockholm Syndrome having spent so many years working in Rails apps.

I'm anxious to give @jessicard's Gulp replacement a try.