gulpfile.js

gulp.task('sass', function() {
  return gulp.src('assets/sass/**/*.scss')
    .pipe(plumber(plumberOptions))
    .pipe(sass(sassOptions))
    .pipe(autoprefixer(autoprefixerOptions))
    .pipe(gulp.dest('assets/css'))
    .pipe(filter(sassFilterOptions))
    .pipe(reload(sassReloadOptions));
});

gulp.task('sass-jekyll', function() {
  return gulp.src('assets/sass/**/*.scss')
    .pipe(plumber(plumberOptions))
    .pipe(sass(sassOptions))
    .pipe(autoprefixer(autoprefixerOptions))
    .pipe(gulp.dest('_site/assets/css'))
    .pipe(filter(sassFilterOptions))
    .pipe(reload(sassReloadOptions));
});

Thanks for the input! Coincidentally, I was just reading about gulp-env and gulp-if, even minimist or yargs alongside gulp-if to do the same. Otherwise is there a way of accomplishing it without using flags/arguments?—my mind still tends to think in a Grunt-like manner, so was curious.

The only reason I bring this up because ultimately I'd like to hook up a watch task to sass-jekyll, but with arguments I couldn't pass in sass --jekyll in the watch task. I could probably use grunt-shell and create a custom task sass-jekyll which ultimately passes in gulp sass --jekyll into the command line and run it that way, but was exploring to see if there was a more elegant of doing it.

@jonsuh, correct me if I'm wrong, but I'm pretty sure you can pipe a second destination in there.

gulp.task('sass', function() {
  return gulp.src('assets/sass/**/*.scss')
    .pipe(plumber(plumberOptions))
    .pipe(sass(sassOptions))
    .pipe(autoprefixer(autoprefixerOptions))
    .pipe(gulp.dest('assets/css'))
    .pipe(gulp.dest('_site/assets/css'))
    .pipe(filter(sassFilterOptions))
    .pipe(reload(sassReloadOptions));
});

That being said, I've used the minimist & gulp-if approach to switch the build destination with a flag before, which does work well for creating a production build before pushing to the production server.

Todd, your approach does work, but in my specific scenario I'm looking to avoid it. The reason is because it triggers Jekyll’s auto-regeneration, and relying on Jekyll to auto-regenerate the changed CSS is slow, which is why I have a separate task to build the CSS directly into Jekyll’s build folder _site.