I've created a Gem which copies sass stylesheets to a specified install location. However, I'm now working on another Gem which will contain sass stylesheets which don't need to be copied to a project.
What I'm wanting to be able to do, if possible, is to add the path to the sass stylesheets within my gem and import them from there as opposed to including them in every single project which in the long term would be useless and potentially a headache to maintain.
For example, I create a gem called sassext which contains all the stylesheets. Then within my projects I can do the following;
#import 'sassext/foobar'
Ideally, I want to be able to use the sass --watch tools as opposed to create my own.
Cheers
P.S. Any links to relevant information/guides would also be appreciated.
Related
I am doing some wordpress development and I am struggling to setup my development environment is a comfortable way. I am building a parent theme and a child theme. Each theme has its own set of sass files. I want to compile the parent themes files only when I make edits to those parent theme stylesheets. I want to compile the child theme stylesheets only when I make edits to those stylesheets.
I am using live-sass-compiler extension to compile my sass. I am open to using a different method for compiling, maybe something like Gulp.
Right now, I have split my parent and child into two different workspaces. I've added my .vscode/settings.json files into each of the parent and child theme folders since they are both the root folder now.
I don't like this setup because I have to use two vscode windows and also vscode can't see all of the functions Wordpress provides via intellisense.
Do you have any recommendations? Should I setup a gulp task instead to compile my sass?
Like you talked about, Gulp is an excellent idea to control your Sass compilation "flow" from start to finish, even conditionally run one pipeline for file A, and a different one for file B. There are a lot of plugins you can use with PostCSS to future-proof your code, for example.
You can have a look at this Gulp Sass tutorial to get the hang of it, using npm.
I'm using SASS 3.3.8 and Compass 1.0.0.alpha.19.
In the interest of shortening SASS compile times in my project, I have split my stylesheets, #import-ing shared mixins, variables, and placeholder selectors. My project file structure looks like this:
scss/
library/
_library.scss
_section_a_widgets.scss
_section_b_widgets.scss
section_b.scss
section_a.scss
In section_a.scss, I have:
#import "library";
#import "section_a_widgets";
In section_b.scss, I have:
#import "library";
#import "section_b_widgets";
This way, when I am working on, e.g., section_a_widgets.scss, I should only have to wait for section_a.scss to compile.
For some reason when I save section_a_widgets.scss, my Compass task indicates that section_a.scss has been "overwritten" (this makes sense), but also indicates that section_b.scss is "identical". This does not make sense to me, as nothing in section_a_widgets.scss is being included in sction_b.scss, and it defeats the purpose of splitting my stylesheets because Compass needs nearly as much time to reach the conclusion that the file was identical, as it does to overwrite the file with new changes.
Does anyone have insight into where I could have gone wrong in my setup? My goal is to reach a point where when I save section_a_widgets.scss, section_a.scss would be "overwritten", but section_b.scss would be "unchanged" (indicating Compass did not bother to try to compile it).
Thanks!
So, due to the information gathered on the comments, the main issue here is that grunt-contrib-compass is executing compass through compass compile command and not through compass watch.
This means, that every time the task is executed, it will go through all your assets and process them. If they are identical, nothing will happen, but as you said, you will loose time analyzing them.
What you are looking for is compass watch, which will be executed every time a file change and only on the files that had been changed. This is useful to have as a task that is working on the background, and if you have this task active, you will get your desired results.
Notice that this will work during your work time, I mean, you have this task running, you modify your files and only the affected ones will be recompiled, and the other ones, ignored.
You have to read the documents in order to set up this environment. On their official repository page, there are some examples you can check out: check here.
Hope this helps and put you on the good track !
By including #import "compass/reset"; in my .scss file, I can have Compass automatically include a simple HTML5 reset. I'd like to use a different reset, so how can I add my own reset to Compass, or change the default one?
The simplest way would be to create a partial in the same directory like _reset.scss and import that.
The easiest way that would allow you to use it across projects would be to create your own Compass extension.
If you create a gem out of it (even just locally), you can just require it in your config.rbs and then #import it into your .scss files.
I have started trying out Sass for my css work. In the directory where my Css file resides I see a '.sass-cache' folder too. Can any one tell me why is this folder created and is it safe if I delete it.
thanks,
By default, Sass caches compiled templates and partials. This dramatically speeds up re-compilation of large collections of Sass files, and works best if the Sass templates are split up into separate files that are all #imported into one large file.
Without a framework, Sass puts the cached templates in the .sass-cache directory. In Rails and Merb, they go in tmp/sass-cache. The directory can be customized with the :cache_location option.
If you don’t want Sass to use caching at all, set the :cache option to false.
You can configure the Sass cache location by setting a Sass option in your compass configuration file like so:
sass_options = {:cache_location => "path\to\tmp\sass-cache"}
Source: Sass reference
If your main problem is "inhibiting pushes to development environments when multiple developers use/change it", you can add it to your .gitignore file. As stated in the other answer, Sass cache files speed up compilation based on whether a Sass file has changed since last compile.
In my experience it's standard practice to consider them temporary files, and omit them from version control.
I'm playing with Padrino, experimenting with a very minimal site at the moment with no DB and just a few HAML and SASS files under the app/ directory.
What I've noticed is that each time I render a page which links to a stylesheet that's defined in a .sass file, it compiles the stylesheet to .css and stores it under public/.
This is all very well, but I also have some static assets stored in public/, including images and some other hand-written .css files.
What this means is that my public/ directory becomes a mix of things I placed there and things compiled by Padrino. So, looking in there will show a bunch of .css files, some of which are compiled .sass files, and some of which are my actual primary static assets. This is confusing.
Is there a way I can stop Padrino (or Sinatra, or Rack, or whatever is doing it) from saving these compiled files during development, and keep my public/ clean?
Alternatively, can someone explain why what I'm asking for is a bad idea / by design / I should learn to love it instead? :-)
Thanks.
I don't know how to set the SASS settings for Padrino, I had a look and couldn't find anything helpful either. I would feel a bit nervous about running it this way too, it could easily get confusing and unhelpful, and what if the asset names clash?
What you could do is not add SASS in via Padrino, and then run it yourself either via the --watch switch or via something like Guard. That way you can also specify different subfolders within the public directory (images/css/js etc), which is what I do (although it does mean you need to remember to add the subfolder as part of the path when describing links). The app doesn't even need to know you're using SASS, and precompilation, when it's this simple, is surely better than the kind of compilation on demand that you've got at the moment (IMO).
You might try the Padrino mailing list for help with the settings.
Using the padrino-sprockets gems I also wanted to change the default /public/stylesheets directory to /assets/stylesheets where sprockets pick them up. I found that my padrino project genereated with the -c sass option had a /lib/sass_plugin.rb file with the following:
# Enables support for SASS template reloading for rack.
# Store SASS files by default within 'app/stylesheets/sass'
# See http://nex-3.com/posts/88-sass-supports-rack for more details.
module SassInitializer
def self.registered(app)
require 'sass/plugin/rack'
Sass::Plugin.options[:template_location] = File.join(Padrino.root, "app/stylesheets")
Sass::Plugin.options[:css_location] = File.join(Padrino.root, "public/stylesheets")
app.use Sass::Plugin::Rack
end
end
Editing the :css_location path and restarting Padrino did the trick!