Manipulating Sass file before running gulp-ruby-sass

[AlbertoElias]

If gulp-ruby-sass is now a source adapter, is there any way I can apply it midway in a gulp stream? In my case, I want to prefix some text to the Sass file before compiling it and I'm not sure how to go around this.

Modifying the file on disk, compiling, and then modifying it again to go back to the original seems like quite a hassle.

What's the best way to go around this?

Thanks

[robwierzbowski]

Can you give me a description of exactly what you're trying to achieve? Is there a reason you can't modify the processed CSS files?

Ruby Sass is meant to work on the filesystem, so we've prioritized sourcemaps and sass functions that read off the filesystem over processing Sass files before compilation. But there's usually a way to work around that to get what you want.

[AlbertoElias]

Like I said, I want to prefix some Sass to set a variable to a specific value, so before I was running something like this:

gulp.src('.main.scss')
  .pipe(prefixer('$my-random-variable: "randomvalue";')
  .pipe(sass({ // config })
  .pipe(gulp.dest('demos')

I don't want this variable to be modified in the file itself, if so, I would have set it manually. This is only for when I build the Sass for the component demos to be run locally, it's a very specific usecase of this component's Sass.

[thebalkanfella]

+1

I want to use scss-lint before compiling sass to css.

[robwierzbowski]

@AlbertoElias You could write a Ruby file that creates a variable with a random value and require that in your Sass config. You could also make a task that acts on the file system and edits a single Sass file with the variable in it, save it to a temp file (which is imported in your main sass files), then run gulp-ruby-sass.

@Pidov You don't need to do that in a stream — sass-lint doesn't change any files. You can run your Sass task as a dependent task of the sass-lint task.

We had to decide whether to make gulp-ruby-sass a source adapter to support major Sass features like sourcemaps, and improve performance, or process files in an active stream to support use cases like these.

With some cleverness, usually requiring Ruby files or making temp files, you can usually get around altering Sass source before running Sass. I know it would be better if you could do both, but Sass is built to work off the file system and we have to make compromises to get a working gulp integration out.

Good luck. Closing this for now as won't fix.

[UltCombo]

@robwierzbowski @AlbertoElias perhaps grs could make use of vinyl-fs-tree in the future? See gulpjs/gulp#357

[robwierzbowski]

That could be promising. Grs and Browserify are pretty similar from what I
know. Thanks!

On Tuesday, April 7, 2015, Fabrício Matté notifications@github.com wrote:

@robwierzbowski https://github.com/robwierzbowski @AlbertoElias
https://github.com/AlbertoElias perhaps grs could make use of
vinyl-fs-tree in the future? See gulpjs/gulp#357
gulpjs/gulp#357

—
Reply to this email directly or view it on GitHub
#217 (comment)
.

Rob Wierzbowski
@robwierzbowski http://twitter.com/#!/robwierzbowski
http://github.com/robwierzbowski
http://robwierzbowski.com

[AlbertoElias]

@UltCombo That definitely does sound promising. I will have to go with the tmp folder solution for now then

[UltCombo]

Although it does sound promising, there may be nits with that approach as well, e.g. the built-in Sass caching will most likely not work. That was one of the reasons @robwierzbowski changed this plugin into a vinyl source adapter IIRC.

[robwierzbowski]

Took a closer look at vinyl-fs-tree today. It's not going to be useful for grs, unfortunately. Users did not like passing their dependencies (partials, referenced image files, etc.) to gulp.src, which using vynil-fs-tree would require. In a larger Compass project with sprite sheets and the like this would be very difficult. Reading those files off of disk is one of the reasons we made this a source adapter.