Support for custom paths in Sass, Less and Coffee #58

wants to merge 4 commits into

5 participants


Hi Tim,

I replaced hardcoded paths to stylesheets and scripts, like public/stylesheets/sass, with some fancy path detection.

The detection depends on the corresponding gem being declared in Gemfile/environment.rb, then proceeds to look for files in a list of possible directories (like app/stylesheets, which seems pretty popular), then falls back to retrieving the path from the app itself (slow but sure, and only in rare cases).

Works with Sass, Less, and Coffeescript; I only tested it on Sass since that's what was available.

It's my first experience with vimscript - I tried to be nice. :)



Great idea! For example I have CoffeeScript files inside app/coffeescripts.


How does Rails 3.1 asset handling affect this?

The sheer volume of code in this pull request made me squirm, so I've kind of let it sit.


If you mean that introducing a standard convention for .sass and .coffee locations will deprecate this code - well, I do hope it will.

But in my opinion, existing 3.0 and 2.3 applications won't migrate to sprockets, even if they upgrade to 3.1, so for them the problem of locating the correct path remains.

Other than that, the only thing that 3.1 changes is that app/javascripts should be added to the list of .coffee default locations.


I've gave the matter more thought, and it looks like the "asset pipeline" makes opening the correct file from Vim a much more complex process.

So, I'll look more into the logic and probably submit another patch. Rails 3.1 will probably make the current asset-related commands useless.


What's the current thinking on this? Now that the asset pipeline has started to catch on, I'd like to simplify a bit, perhaps dropping app/scripts and app/stylesheets (which, if memory serves, weren't supported back when this pull request was introduced).

In theory, the new config/editor.json projections should allow for people stuck on nonstandard setups to override :Rjavascript and :Rstylesheet.


@tpope Could projections also be used to switch the order of preference :Rjavascript and :Rstylesheet for new files? That is, could a projection be used to put new files into app/assets/javascripts?

Also, at this point in time, should we invert the above? Default to app/assets and let a projection handle forcing public?


The problem with sticking new files under app/assets is that we don't know what extension to give them. .js? Rails further complicates this with its infuriatingly mushy file name handling, allowing such bastardizations as .coffee and .coffee.erb (and maybe even a naked .erb for all I know). And if that wasn't bad enough, CSS adds both SCSS and Sass to the mix, so we can't just look at what gems are installed.

What does rails generate create? Is it customizable? Can we detect that and use it to guide our default?


Crazy idea... what about looking at the surrounding files as a guideline? For example, if there are 2 files in app/assets/javascripts, but only .js file, we go with the extension. The same would work for stylesheets because presumably people either prefer .sass or .scss, but not both.

Basically, rather than deciding a default based on Rails "conventions" or generators, we let the existing project decide.

Crazy? Or craziest?


@tpope You can of course make your own rails generator; however, I am unsure whether you can customize the built in ones.

I really believe this feature should be: if they input 1 or more file extensions explicitly, then that should be the file name (don't add anything); if they don't then it should default to the core language extension for that particular context. The core extension for a stylesheet being simply .css. The core extension for a view being simply .html. Since these extensions are the "base" extensions for a website, this fallback won't break for a long time. So you have to enter .html.erb if you want the erb... Big deal. It's better than it breaking for the other guy who uses .html.haml.

This method seems like it would take a lot less code than any other route, and yet solve the problem. Would this be difficult to implement?


File creation is now correctly handled based on configured generators. I'm thinking that should address all remaining concerns here.

@tpope tpope closed this Mar 29, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment