Convert Figma logo to code with AI

webpack-contrib logosass-loader

Compiles Sass to CSS

3,900
428
3,900
4

Top Related Projects

:rainbow: Node.js bindings to libsass

The reference implementation of Sass, written in Dart.

PostCSS loader for webpack

CSS Loader

Style Loader

43,380

The zero configuration build tool for the web. 📦🚀

Quick Overview

The sass-loader is a webpack loader for compiling Sass/SCSS files to CSS. It integrates Sass compilation into the webpack build process, allowing developers to use Sass in their projects while leveraging webpack's module bundling capabilities.

Pros

  • Seamless integration with webpack ecosystem
  • Supports both Sass and SCSS syntax
  • Allows for easy import of Sass files in JavaScript
  • Configurable with various options for customization

Cons

  • Requires additional setup compared to using plain CSS
  • Can increase build times for large projects with many Sass files
  • Potential version conflicts with Sass compiler
  • May require additional loaders (e.g., css-loader) for full functionality

Code Examples

  1. Basic usage in webpack configuration:
module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          'style-loader',
          'css-loader',
          'sass-loader',
        ],
      },
    ],
  },
};
  1. Importing Sass in JavaScript:
import './styles.scss';
  1. Using with postcss-loader:
module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          'style-loader',
          'css-loader',
          'postcss-loader',
          'sass-loader',
        ],
      },
    ],
  },
};

Getting Started

  1. Install the required packages:
npm install sass-loader sass webpack --save-dev
  1. Add sass-loader to your webpack configuration:
module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          'style-loader',
          'css-loader',
          'sass-loader',
        ],
      },
    ],
  },
};
  1. Create a Sass file (e.g., styles.scss) and import it in your JavaScript:
import './styles.scss';
  1. Run webpack to build your project, and the Sass files will be compiled and included in your bundle.

Competitor Comparisons

:rainbow: Node.js bindings to libsass

Pros of node-sass

  • Faster compilation speed for large projects
  • Direct C++ bindings to LibSass, offering better performance
  • Can be used as a standalone tool without Webpack

Cons of node-sass

  • Deprecated and no longer actively maintained
  • Limited compatibility with newer Sass features
  • May require manual rebuilding for different Node.js versions

Code Comparison

node-sass:

var sass = require('node-sass');
sass.render({
  file: 'input.scss',
  outFile: 'output.css',
  outputStyle: 'compressed'
}, function(error, result) {
  // Handle result
});

sass-loader:

// webpack.config.js
module.exports = {
  module: {
    rules: [{
      test: /\.scss$/,
      use: ['style-loader', 'css-loader', 'sass-loader']
    }]
  }
};

Key Differences

  • sass-loader is specifically designed for Webpack integration, while node-sass can be used independently
  • sass-loader supports the latest Sass features and is actively maintained
  • node-sass offers better performance for large projects but lacks modern Sass feature support
  • sass-loader provides a more streamlined workflow within Webpack ecosystems
  • node-sass requires manual configuration for output, while sass-loader integrates seamlessly with Webpack's build process

The reference implementation of Sass, written in Dart.

Pros of dart-sass

  • Standalone Sass implementation, not dependent on webpack or other build tools
  • Faster compilation times, especially for large projects
  • Supports the latest Sass features and syntax

Cons of dart-sass

  • Requires additional setup when integrating with webpack
  • May have compatibility issues with some older Sass libraries or mixins
  • Limited built-in options for source maps compared to sass-loader

Code Comparison

sass-loader (webpack configuration):

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: ['style-loader', 'css-loader', 'sass-loader']
      }
    ]
  }
};

dart-sass (Node.js usage):

const sass = require('sass');

const result = sass.renderSync({
  file: 'input.scss',
  outputStyle: 'compressed'
});

The sass-loader is specifically designed for webpack integration, making it easier to use within a webpack build process. It handles the compilation of Sass files as part of the module bundling.

dart-sass, on the other hand, is a more versatile Sass implementation that can be used in various environments, including command-line interfaces, build tools, and server-side rendering. It offers more flexibility but requires additional configuration when used with webpack.

Both projects aim to provide Sass compilation capabilities, but they serve different use cases and have distinct advantages depending on the development environment and project requirements.

PostCSS loader for webpack

Pros of postcss-loader

  • More flexible and extensible with a wide range of plugins
  • Can handle modern CSS features and syntax
  • Faster processing times for large projects

Cons of postcss-loader

  • Steeper learning curve due to plugin ecosystem
  • May require additional configuration for full functionality

Code Comparison

sass-loader:

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: ['style-loader', 'css-loader', 'sass-loader']
      }
    ]
  }
};

postcss-loader:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader', 'postcss-loader']
      }
    ]
  }
};

Summary

postcss-loader offers more flexibility and modern CSS support, but may require more setup. sass-loader is simpler to use but limited to Sass syntax. Both loaders integrate well with webpack and can be used in combination for optimal CSS processing.

CSS Loader

Pros of css-loader

  • Handles CSS imports and url() resolving
  • Supports CSS Modules out of the box
  • Smaller in size and more focused on CSS processing

Cons of css-loader

  • Doesn't compile Sass/SCSS files directly
  • Requires additional loaders for preprocessing (e.g., sass-loader)

Code Comparison

css-loader usage:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        use: ["style-loader", "css-loader"],
      },
    ],
  },
};

sass-loader usage:

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/i,
        use: ["style-loader", "css-loader", "sass-loader"],
      },
    ],
  },
};

Key Differences

  • css-loader focuses on processing and bundling CSS files, while sass-loader is specifically for compiling Sass/SCSS to CSS
  • sass-loader requires css-loader in its chain to work effectively
  • css-loader is more versatile for general CSS processing, while sass-loader adds Sass compilation capabilities

Use Cases

  • Use css-loader for projects with plain CSS or when using other preprocessors
  • Use sass-loader (along with css-loader) for projects utilizing Sass/SCSS

Community and Maintenance

Both loaders are part of the webpack-contrib organization, ensuring consistent maintenance and integration with the webpack ecosystem. They have active communities and regular updates.

Style Loader

Pros of style-loader

  • Injects CSS into the DOM at runtime, allowing for dynamic styling
  • Supports hot module replacement (HMR) for styles out of the box
  • Smaller bundle size as styles are not extracted into separate files

Cons of style-loader

  • Can cause Flash of Unstyled Content (FOUC) as styles are applied after JavaScript loads
  • Not ideal for production builds where separate CSS files are preferred for caching
  • Limited preprocessing capabilities compared to sass-loader

Code Comparison

style-loader:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  }
};

sass-loader:

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: ['style-loader', 'css-loader', 'sass-loader']
      }
    ]
  }
};

Summary

style-loader is focused on injecting CSS into the DOM, making it great for development and applications requiring dynamic styling. It's lightweight and supports HMR, but may not be ideal for production builds. sass-loader, on the other hand, preprocesses Sass/SCSS files into CSS, offering more advanced styling capabilities. It's often used in conjunction with style-loader or other CSS extraction plugins for a complete styling solution in webpack projects.

43,380

The zero configuration build tool for the web. 📦🚀

Pros of Parcel

  • Zero configuration required, works out of the box
  • Faster build times due to built-in caching and multicore processing
  • Supports a wide range of file types and assets without additional plugins

Cons of Parcel

  • Less flexibility and customization options compared to Webpack ecosystem
  • Smaller community and ecosystem, potentially fewer resources and third-party integrations

Code Comparison

sass-loader (used with Webpack):

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: ['style-loader', 'css-loader', 'sass-loader']
      }
    ]
  }
};

Parcel (no configuration needed):

<link rel="stylesheet" href="./styles.scss">

Summary

Parcel offers a simpler, zero-configuration approach to bundling, making it easier for beginners and small to medium-sized projects. It provides faster build times and supports various file types out of the box. However, sass-loader with Webpack offers more flexibility and customization options, which can be beneficial for larger, more complex projects. The Webpack ecosystem also has a larger community and more resources available. The choice between the two depends on project requirements, team expertise, and desired level of control over the bundling process.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

npm node tests coverage discussion size

sass-loader

Loads a Sass/SCSS file and compiles it to CSS.

Getting Started

To begin, you'll need to install sass-loader:

npm install sass-loader sass webpack --save-dev

or

yarn add -D sass-loader sass webpack

or

pnpm add -D sass-loader sass webpack

[!NOTE]

To enable CSS processing in your project, you need to install style-loader and css-loader via npm i style-loader css-loader.

sass-loader requires you to install either Dart Sass, Node Sass on your own (more documentation can be found below) or Sass Embedded.

This allows you to control the versions of all your dependencies, and to choose which Sass implementation to use.

[!NOTE]

We highly recommend using Sass Embedded or Dart Sass.

[!WARNING]

Node Sass does not work with Yarn PnP and doesn't support @use rule.

Chain the sass-loader with the css-loader and the style-loader to immediately apply all styles to the DOM or the mini-css-extract-plugin to extract it into a separate file.

Then add the loader to your webpack configuration. For example:

app.js

import "./style.scss";

style.scss

$body-color: red;

body {
  color: $body-color;
}

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          // Creates `style` nodes from JS strings
          "style-loader",
          // Translates CSS into CommonJS
          "css-loader",
          // Compiles Sass to CSS
          "sass-loader",
        ],
      },
    ],
  },
};

Finally run webpack via your preferred method.

The outputStyle (old API) and style (new API) options in production mode

For production mode, the outputStyle (old API) and style (new API) options default to compressed unless otherwise specified in sassOptions.

Resolving import at-rules

Webpack provides an advanced mechanism to resolve files.

The sass-loader uses Sass's custom importer feature to pass all queries to the webpack resolving engine enabling you to import your Sass modules from node_modules.

@import "bootstrap";

Using ~ is deprecated and should be removed from your code, but we still support it for historical reasons. Why can you remove it? The loader will first try to resolve @import as a relative path. If it cannot be resolved, then the loader will try to resolve @import inside node_modules.

Prepending module paths with a ~ tells webpack to search through node_modules.

@import "~bootstrap";

It's important to prepend the path with only ~, because ~/ resolves to the home directory. Webpack needs to distinguish between bootstrap and ~bootstrap because CSS and Sass files have no special syntax for importing relative files. Writing @import "style.scss" is the same as @import "./style.scss";

Problems with url(...)

Since Sass implementations don't provide url rewriting, all linked assets must be relative to the output.

  • If you pass the generated CSS on to the css-loader, all urls must be relative to the entry-file (e.g. main.scss).
  • If you're just generating CSS without passing it to the css-loader, it must be relative to your web root.

You might be surprised by this first issue, as it is natural to expect relative references to be resolved against the .sass/.scss file in which they are specified (like in regular .css files).

Thankfully there are two solutions to this problem:

  • Add the missing url rewriting using the resolve-url-loader. Place it before sass-loader in the loader chain.
  • Library authors usually provide a variable to modify the asset path. bootstrap-sass for example has an $icon-font-path.

Options

implementation

Type:

type implementation = object | string;

Default: sass

The special implementation option determines which implementation of Sass to use.

By default, the loader resolves the implementation based on your dependencies. Just add the desired implementation to your package.json (sass, sass-embedded, or node-sass package) and install dependencies.

Example where the sass-loader loader uses the sass (dart-sass) implementation:

package.json

{
  "devDependencies": {
    "sass-loader": "^7.2.0",
    "sass": "^1.22.10"
  }
}

Example where the sass-loader loader uses the node-sass implementation:

package.json

{
  "devDependencies": {
    "sass-loader": "^7.2.0",
    "node-sass": "^5.0.0"
  }
}

Example where the sass-loader loader uses the sass-embedded implementation:

package.json

{
  "devDependencies": {
    "sass-loader": "^7.2.0",
    "sass": "^1.22.10"
  },
  "optionalDependencies": {
    "sass-embedded": "^1.70.0"
  }
}

[!NOTE]

Using optionalDependencies means that sass-loader can fallback to sass when running on an operating system not supported by sass-embedded

Be aware of the order that sass-loader will resolve the implementation:

  1. sass-embedded
  2. sass
  3. node-sass

You can specify a specific implementation by using the implementation option, which accepts one of the above values.

object

For example, to always use Dart Sass, you'd pass:

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              // Prefer `dart-sass`, even if `sass-embedded` is available
              implementation: require("sass"),
            },
          },
        ],
      },
    ],
  },
};

string

For example, to use Dart Sass, you'd pass:

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              // Prefer `dart-sass`, even if `sass-embedded` is available
              implementation: require.resolve("sass"),
            },
          },
        ],
      },
    ],
  },
};

sassOptions

Type:

type sassOptions =
  | import("sass").LegacyOptions<"async">
  | ((
      content: string | Buffer,
      loaderContext: LoaderContext,
      meta: any,
    ) => import("sass").LegacyOptions<"async">);

Default: defaults values for Sass implementation

Options for Dart Sass or Node Sass implementation.

[!NOTE]

The charset option is true by default for dart-sass, we strongly discourage setting this to false, because webpack doesn't support files other than utf-8.

[!NOTE]

The indentedSyntax option is true for the sass extension.

[!NOTE]

Options such as data and file are unavailable and will be ignored.

ℹ We strongly discourage changing the outFile, sourceMapContents, sourceMapEmbed, and sourceMapRoot options because sass-loader sets these automatically when the sourceMap option is true.

[!NOTE]

Access to the loader context inside the custom importer can be done using the this.webpackLoaderContext property.

There is a slight difference between the options for sass (dart-sass) and node-sass.

Please consult their respective documentation before using them:

object

Use an object for the Sass implementation setup.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              sassOptions: {
                indentWidth: 4,
                includePaths: ["absolute/path/a", "absolute/path/b"],
              },
            },
          },
        ],
      },
    ],
  },
};

function

Allows configuring the Sass implementation with different options based on the loader context.

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              sassOptions: (loaderContext) => {
                // More information about available properties https://webpack.js.org/api/loaders/
                const { resourcePath, rootContext } = loaderContext;
                const relativePath = path.relative(rootContext, resourcePath);

                if (relativePath === "styles/foo.scss") {
                  return {
                    includePaths: ["absolute/path/c", "absolute/path/d"],
                  };
                }

                return {
                  includePaths: ["absolute/path/a", "absolute/path/b"],
                };
              },
            },
          },
        ],
      },
    ],
  },
};

sourceMap

Type:

type sourceMap = boolean;

Default: depends on the compiler.devtool value

Enables/Disables generation of source maps.

By default generation of source maps depends on the devtool option. All values enable source map generation except eval and false.

ℹ If true, the sourceMap, sourceMapRoot, sourceMapEmbed, sourceMapContents and omitSourceMapUrl options from sassOptions will be ignored.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              sourceMap: true,
            },
          },
          {
            loader: "sass-loader",
            options: {
              sourceMap: true,
            },
          },
        ],
      },
    ],
  },
};

ℹ In some rare cases node-sass can output invalid source maps (it is a node-sass bug).

In order to avoid this, you can try to update node-sass to latest version, or you can try to set within sassOptions the outputStyle option to compressed.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              sourceMap: true,
              sassOptions: {
                outputStyle: "compressed",
              },
            },
          },
        ],
      },
    ],
  },
};

additionalData

Type:

type additionalData =
  | string
  | ((content: string | Buffer, loaderContext: LoaderContext) => string);

Default: undefined

Prepends Sass/SCSS code before the actual entry file. In this case, the sass-loader will not override the data option but just prepend the entry's content.

This is especially useful when some of your Sass variables depend on the environment:

string

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              additionalData: "$env: " + process.env.NODE_ENV + ";",
            },
          },
        ],
      },
    ],
  },
};

function

Sync
module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              additionalData: (content, loaderContext) => {
                // More information about available properties https://webpack.js.org/api/loaders/
                const { resourcePath, rootContext } = loaderContext;
                const relativePath = path.relative(rootContext, resourcePath);

                if (relativePath === "styles/foo.scss") {
                  return "$value: 100px;" + content;
                }

                return "$value: 200px;" + content;
              },
            },
          },
        ],
      },
    ],
  },
};
Async
module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              additionalData: async (content, loaderContext) => {
                // More information about available properties https://webpack.js.org/api/loaders/
                const { resourcePath, rootContext } = loaderContext;
                const relativePath = path.relative(rootContext, resourcePath);

                if (relativePath === "styles/foo.scss") {
                  return "$value: 100px;" + content;
                }

                return "$value: 200px;" + content;
              },
            },
          },
        ],
      },
    ],
  },
};

webpackImporter

Type:

type webpackImporter = boolean;

Default: true

Enables/Disables the default webpack importer.

This can improve performance in some cases, though use it with caution because aliases and @import at-rules starting with ~ will not work. You can pass your own importer to solve this (see importer docs).

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              webpackImporter: false,
            },
          },
        ],
      },
    ],
  },
};

warnRuleAsWarning

Type:

type warnRuleAsWarning = boolean;

Default: true

Treats the @warn rule as a webpack warning.

style.scss

$known-prefixes: webkit, moz, ms, o;

@mixin prefix($property, $value, $prefixes) {
  @each $prefix in $prefixes {
    @if not index($known-prefixes, $prefix) {
      @warn "Unknown prefix #{$prefix}.";
    }

    -#{$prefix}-#{$property}: $value;
  }
  #{$property}: $value;
}

.tilt {
  // Oops, we typo'd "webkit" as "wekbit"!
  @include prefix(transform, rotate(15deg), wekbit ms);
}

The presented code will throw a webpack warning instead logging.

To ignore unnecessary warnings you can use the ignoreWarnings option.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              warnRuleAsWarning: true,
            },
          },
        ],
      },
    ],
  },
};

api

Type:

type api = "legacy" | "modern" | "modern-compiler";

Default: "modern" for sass (dart-sass) and sass-embedded or "legacy" for node-sass

Allows you to switch between the legacy and modern APIs. You can find more information here. The modern-compiler option enables the modern API with support for Shared Resources.

[!NOTE]

Using modern-compiler and sass-embedded together significantly improve performance and decrease built time. We strongly recommend their use. We will enable them by default in a future major release.

[!WARNING]

The sass options are different for the legacy and modern APIs. Please look at docs how to migrate to the modern options.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              api: "modern-compiler",
              sassOptions: {
                // Your sass options
              },
            },
          },
        ],
      },
    ],
  },
};

How to enable @debug output

By default, the output of @debug messages are disabled. Add the following to webpack.config.js to enable them:

module.exports = {
  stats: {
    loggingDebug: ["sass-loader"],
  },
  // ...
};

Examples

Extracts CSS into separate files

For production builds it's recommended to extract the CSS from your bundle to be able to use parallel loading of CSS/JS resources later on.

There are four recommended ways to extract a stylesheet from a bundle:

1. mini-css-extract-plugin

webpack.config.js

const MiniCssExtractPlugin = require("mini-css-extract-plugin");

module.exports = {
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          // fallback to style-loader in development
          process.env.NODE_ENV !== "production"
            ? "style-loader"
            : MiniCssExtractPlugin.loader,
          "css-loader",
          "sass-loader",
        ],
      },
    ],
  },
  plugins: [
    new MiniCssExtractPlugin({
      // Options similar to the same options in webpackOptions.output
      // both options are optional
      filename: "[name].css",
      chunkFilename: "[id].css",
    }),
  ],
};

2. Asset Modules

webpack.config.js

module.exports = {
  entry: [__dirname + "/src/scss/app.scss"],
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [],
      },
      {
        test: /\.scss$/,
        exclude: /node_modules/,
        type: "asset/resource",
        generator: {
          filename: "bundle.css",
        },
        use: ["sass-loader"],
      },
    ],
  },
};

3. extract-loader (simpler, but specialized on the css-loader's output)

4. file-loader (deprecated--should only be used in webpack v4)

webpack.config.js

module.exports = {
  entry: [__dirname + "/src/scss/app.scss"],
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [],
      },
      {
        test: /\.scss$/,
        exclude: /node_modules/,
        use: [
          {
            loader: "file-loader",
            options: { outputPath: "css/", name: "[name].min.css" },
          },
          "sass-loader",
        ],
      },
    ],
  },
};

(source: https://stackoverflow.com/a/60029923/2969615)

Source maps

Enables/Disables generation of source maps.

To enable CSS source maps, you'll need to pass the sourceMap option to the sass-loader and the css-loader.

webpack.config.js

module.exports = {
  devtool: "source-map", // any "source-map"-like devtool is possible
  module: {
    rules: [
      {
        test: /\.s[ac]ss$/i,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              sourceMap: true,
            },
          },
          {
            loader: "sass-loader",
            options: {
              sourceMap: true,
            },
          },
        ],
      },
    ],
  },
};

If you want to edit the original Sass files inside Chrome, there's a good blog post. Checkout test/sourceMap for a running example.

Contributing

Please take a moment to read our contributing guidelines if you haven't yet done so.

CONTRIBUTING

License

MIT

NPM DownloadsLast 30 Days