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:
- 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';
. - 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. - In
vendor/assets
. I believe this is where you would put third-party CSS, JS, etc. (e.g. Normalize.css, jQuery). Libraries, basically. - 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 inapplication.css.scss
with lines like@import fonts;
(which maps toapp/assets/stylesheets/_fonts.scss
),@import base/*;
(which includes all SCSS files inapp/assets/stylesheets/base/
), and@import "components/**/*";
(which includes all SCSS files inapp/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.
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 inapplication.js
andapplication.css.scss
. Same goes for most of the gems inGemfile
.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).