I am not a designer, and the only place I use sass is a bunch of static blogs, including my primary one. The command I run to compile my sass files is as follows:
find . -name '*.sass' | onchange -s make css
where onchange is a simple command I've written that watches filesystem for events on files from stdin and runs command when they occur, and make css is simply
sass --update _sass:dynamic/styles
So long as sass is in the $PATH, I'm good to go. I don't care how my sass files are translated to css files, I only care whether they get translated or not. In the last place I worked, they used guard for compiling less (sth. like sass) files and concatenating them, which was a frightening program with a huge configuration file, written in JSON. For concatenation, I'd do
See, when your abstractions are processes, everything is easy. It's like git, one simply does not need to know if git commit is a shell script or a C program. It is a process, you need to call it, and that's it.
edit: put in absent redirection into the last command line.
Comments
I am not a designer, and the only place I use sass is a bunch of static blogs, including my primary one. The command I run to compile my sass files is as follows:
where onchange is a simple command I've written that watches filesystem for events on files from stdin and runs command when they occur, and make css is simply So long as sass is in the $PATH, I'm good to go. I don't care how my sass files are translated to css files, I only care whether they get translated or not. In the last place I worked, they used guard for compiling less (sth. like sass) files and concatenating them, which was a frightening program with a huge configuration file, written in JSON. For concatenation, I'd do See, when your abstractions are processes, everything is easy. It's like git, one simply does not need to know if git commit is a shell script or a C program. It is a process, you need to call it, and that's it.edit: put in absent redirection into the last command line.