grunt-sass and gulp-sass are task runner plugins that enable Sass compilation within Grunt and Gulp workflows, respectively. Both serve as wrappers around the Dart Sass implementation (the primary Sass compiler) and allow developers to integrate .scss or .sass file processing into automated build systems. These packages abstract direct CLI usage of Sass, providing JavaScript APIs that fit naturally into their respective task runner ecosystems, handling file watching, source maps, error reporting, and output configuration as part of larger frontend toolchains.
Both grunt-sass and gulp-sass exist to compile Sass files using Dart Sass within traditional JavaScript task runners. They emerged during the era when Grunt and Gulp dominated frontend build automation—before bundlers like Webpack, Rollup, or Vite became standard. Neither package is deprecated, but both cater primarily to legacy or maintenance-mode codebases. Let’s compare how they work under real-world conditions.
grunt-sass follows Grunt’s philosophy of configuration-driven tasks. You define targets, files, and options in a declarative object structure inside Gruntfile.js.
// Gruntfile.js
module.exports = function(grunt) {
grunt.initConfig({
sass: {
dist: {
options: {
sourceMap: true,
outputStyle: 'compressed'
},
files: {
'dist/main.css': 'src/scss/main.scss'
}
}
}
});
grunt.loadNpmTasks('grunt-sass');
grunt.registerTask('default', ['sass']);
};
gulp-sass aligns with Gulp’s code-first, stream-based approach. You write functions that pipe files through transformation steps using Node.js streams.
// gulpfile.js
const gulp = require('gulp');
const sass = require('gulp-sass')(require('sass'));
function compileSass() {
return gulp.src('src/scss/main.scss')
.pipe(sass({
outputStyle: 'compressed',
sourceMap: true
}).on('error', sass.logError))
.pipe(gulp.dest('dist'));
}
exports.default = compileSass;
💡 Note: As of
gulp-sassv5+, you must pass a Sass implementation (likesassfromsass) explicitly—this decouples the plugin from any specific Sass engine.
grunt-sass uses Grunt’s built-in file mapping. You specify input-output pairs via object keys or expand/cwd patterns. It processes each file independently and writes outputs synchronously per target.
// Multiple files with dynamic naming
files: [{
expand: true,
cwd: 'src/scss',
src: ['*.scss'],
dest: 'dist/css',
ext: '.css'
}]
gulp-sass leverages Gulp’s streaming model. Files flow through the pipeline one by one, enabling composition with other plugins (e.g., autoprefixer, minification) without intermediate disk writes.
const postcss = require('gulp-postcss');
const autoprefixer = require('autoprefixer');
function buildStyles() {
return gulp.src('src/scss/*.scss')
.pipe(sass({ outputStyle: 'expanded' }))
.pipe(postcss([autoprefixer()]))
.pipe(gulp.dest('dist/css'));
}
This makes gulp-sass more flexible for chaining transformations, while grunt-sass requires separate task definitions for each step.
grunt-sass reports errors via Grunt’s standard logging. Compilation failures halt the entire task unless you implement custom error handling (which Grunt doesn’t encourage).
// Errors stop execution; no built-in recovery
options: {
// No native error callback — fails loudly
}
gulp-sass gives you explicit control over error behavior using .on('error', handler). This prevents Gulp from crashing and allows watch tasks to stay alive during development.
.pipe(sass().on('error', sass.logError)) // Keeps watcher running
For active development with file watching, gulp-sass provides a smoother experience out of the box.
Both packages rely on Dart Sass as the underlying compiler—but in different ways:
grunt-sass bundles Dart Sass directly as a dependency. You don’t install sass separately.gulp-sass (v5+) requires you to install sass yourself and pass it into the plugin. This gives you control over the Sass version.// gulp-sass requires explicit injection
const sassCompiler = require('sass');
const sass = require('gulp-sass')(sassCompiler);
This makes gulp-sass more transparent about its dependencies and easier to upgrade independently.
Neither package handles file watching natively—you delegate that to Grunt or Gulp’s own watch mechanisms.
With Grunt, you’d use grunt-contrib-watch:
watch: {
sass: {
files: ['src/scss/**/*.scss'],
tasks: ['sass']
}
}
With Gulp, you use gulp.watch():
function watchFiles() {
gulp.watch('src/scss/**/*.scss', compileSass);
}
Gulp’s approach feels more integrated because the watcher and task share the same runtime context, reducing startup overhead on each change.
No. Modern alternatives offer significant advantages:
.scss files.sass-loader provides better caching and HMR.These tools handle Sass as part of a unified asset graph, enabling features like CSS code splitting, scoped styles, and live reloading that task runners can’t match.
However, if you’re stuck maintaining a Grunt or Gulp codebase, here’s how to choose:
grunt-sass for consistency.gulp-sass with explicit sass injection.But plan a migration path. Task runners were designed for a world without native ES modules, tree-shaking, or dev servers—concepts now central to frontend development.
| Feature | grunt-sass | gulp-sass |
|---|---|---|
| Integration Style | Declarative config object | Procedural stream pipeline |
| File Handling | Static file mappings | Streaming, composable pipes |
| Error Recovery | Halts on error | Custom error handlers keep watch alive |
| Sass Dependency | Bundled internally | Requires manual sass installation |
| Best For | Legacy Grunt projects | Existing Gulp pipelines |
| New Projects? | ❌ Avoid | ❌ Avoid |
If you’re reading this while starting a new app, skip both. Use a modern build tool that treats Sass as a first-class citizen. But if you’re debugging a five-year-old CMS theme or enterprise dashboard still running on Gulp, now you know exactly how these two plugins differ—and why one might fit your legacy stack better than the other.
Choose gulp-sass if your team relies on Gulp for lightweight, stream-based build pipelines and prefers writing procedural build logic in JavaScript over configuration files. While still viable for simple projects, consider whether a more modern bundler like Vite or esbuild might better serve long-term maintainability.
Choose grunt-sass only if you are maintaining a legacy project already built on Grunt and cannot justify migrating to a modern build system. It integrates cleanly with Grunt’s configuration-over-code style but offers no advantage over newer tools and is not recommended for new projects due to Grunt’s declining ecosystem relevance.
Sass plugin for Gulp.
Before filing an issue, please make sure you have updated to the latest version of gulp-sass and have gone through our Common Issues and Their Fixes section.
Migrating your existing project to version 5 or 6? Please read our (short!) migration guides.
Only Active LTS and Current releases are supported.
To use gulp-sass, you must install both gulp-sass itself and a Sass compiler. gulp-sass supports both Embedded Sass, Dart Sass and Node Sass, although Node Sass is deprecated. We recommend that you use Dart Sass for new projects, and migrate Node Sass projects to Dart Sass or Embedded Sass when possible.
Whichever compiler you choose, it's best to install these as dev dependencies:
npm install sass gulp-sass --save-dev
gulp-sass must be imported into your gulpfile, where you provide it the compiler of your choice. To use gulp-sass in a CommonJS module (which is most Node.js environments), do something like this:
const sass = require('gulp-sass')(require('sass'));
To use gulp-sass in an ECMAScript module (which is supported in newer Node.js 14 and later), do something like this:
import dartSass from 'sass';
import gulpSass from 'gulp-sass';
const sass = gulpSass(dartSass);
Note: These examples are written for CommonJS modules and assume you're using Gulp 4. For examples that work with Gulp 3, check the docs for an earlier version of gulp-sass.
gulp-sass must be used in a Gulp task. Your task can call sass() (to asynchronously render your CSS), or sass.sync() (to synchronously render your CSS). Then, export your task with the export keyword. We'll show some examples of how to do that.
⚠️ Note: When using Dart Sass, synchronous rendering is twice as fast as asynchronous rendering. The Sass team is exploring ways to improve asynchronous rendering with Dart Sass, but for now, you will get the best performance from sass.sync(). If performance is critical, you can use sass-embedded instead.
To render your CSS with a build task, then watch your files for changes, you might write something like this:
'use strict';
const gulp = require('gulp');
const sass = require('gulp-sass')(require('sass'));
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sass().on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
exports.buildStyles = buildStyles;
exports.watch = function () {
gulp.watch('./sass/**/*.scss', buildStyles);
};
With synchronous rendering, that Gulp task looks like this:
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sass.sync().on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
To change the final output of your CSS, you can pass an options object to your renderer. gulp-sass supports Sass's JS API compile options, with a few usage notes:
syntax option is set to indented automatically for files with the .sass extensionsourceMap and sourceMapIncludeSources options are set for you when using gulp-sourcemapsFor example, to compress your CSS, you can call sass({style: 'compressed'}. In the context of a Gulp task, that looks like this:
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sass({style: 'compressed'}).on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
exports.buildStyles = buildStyles;
Or this for synchronous rendering:
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sass.sync({style: 'compressed'}).on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
exports.buildStyles = buildStyles;
gulp-sass can be used in tandem with gulp-sourcemaps to generate source maps for the Sass-to-CSS compilation. You will need to initialize gulp-sourcemaps before running gulp-sass, and write the source maps after.
const sourcemaps = require('gulp-sourcemaps');
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(sourcemaps.write())
.pipe(gulp.dest('./css'));
}
exports.buildStyles = buildStyles;
By default, gulp-sourcemaps writes the source maps inline, in the compiled CSS files. To write them to a separate file, specify a path relative to the gulp.dest() destination in the sourcemaps.write() function.
const sourcemaps = require('gulp-sourcemaps');
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sourcemaps.init())
.pipe(sass().on('error', sass.logError))
.pipe(sourcemaps.write('./maps'))
.pipe(gulp.dest('./css'));
};
exports.buildStyles = buildStyles;
gulp-sass version 6 uses the new compile function internally by default. If you use any options, for instance custom importers, please compare the new options with the legacy options in order to migrate. For instance, the outputStyle option is now called style.
function buildStyles() {
return gulp.src('./sass/**/*.scss')
- .pipe(sass({outputStyle: 'compressed'}).on('error', sass.logError))
+ .pipe(sass({style: 'compressed'}).on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
If you want to keep using the legacy API while it's available, you can.
const sass = require('gulp-sass/legacy')(require('sass'));
If you use source maps, you may see the result change somewhat. The result will typically be absolute file: URLs, rather than relative ones. The result may also be the source itself, URL encoded. You can optionally add custom importers to adjust the source maps according to your own needs.
gulp-sass version 5 requires Node.js 12 or later, and introduces some breaking changes. Additionally, changes in Node.js itself mean that Node fibers can no longer be used to speed up Dart Sass in Node.js 16.
As of version 5, gulp-sass does not include a default Sass compiler, so you must install one (either sass, sass-embedded, or node-sass) along with gulp-sass.
npm install sass gulp-sass --save-dev
Then, you must explicitly set that compiler in your gulpfille. Instead of setting a compiler prop on the gulp-sass instance, you pass the compiler into a function call when instantiating gulp-sass.
These changes look something like this:
- const sass = require('gulp-sass'));
- const compiler = require('sass');
- sass.compiler = compiler;
+ const sass = require('gulp-sass')(require('sass'));
If you're migrating an ECMAScript module, that'll look something like this:
import dartSass from 'sass';
- import sass from 'gulp-sass';
- sass.compiler = dartSass;
import dartSass from 'sass';
+ import gulpSass from 'gulp-sass';
+ const sass = gulpSass(dartSass);
If you need to use the deprecated render Sass API, gulp-sass still includes legacy support.
'use strict';
const gulp = require('gulp');
const sass = require('gulp-sass/legacy')(require('sass'));
function buildStyles() {
return gulp.src('./sass/**/*.scss')
.pipe(sass().on('error', sass.logError))
.pipe(gulp.dest('./css'));
};
exports.buildStyles = buildStyles;
exports.watch = function () {
gulp.watch('./sass/**/*.scss', buildStyles);
};
We used to recommend Node fibers as a way to speed up asynchronous rendering with Dart Sass. Unfortunately, Node fibers are discontinued and will not work in Node.js 16. The Sass team is exploring its options for future performance improvements, but for now, you will get the best performance from sass.sync().
gulp-sass is a light-weight wrapper around either Dart Sass or Node Sass (which in turn is a Node.js binding for LibSass. Because of this, the issue you're having likely isn't a gulp-sass issue, but an issue with one those projects or with Sass as a whole.
If you have a feature request/question about how Sass works/concerns on how your Sass gets compiled/errors in your compiling, it's likely a Dart Sass or LibSass issue and you should file your issue with one of those projects.
If you're having problems with the options you're passing in, it's likely a Dart Sass or Node Sass issue and you should file your issue with one of those projects.
We may, in the course of resolving issues, direct you to one of these other projects. If we do so, please follow up by searching that project's issue queue (both open and closed) for your problem and, if it doesn't exist, filing an issue with them.