Stylelint Configuration Packages Compared: Prettier, Recommended, Sass Guidelines, and Standard

When setting up a CSS/SCSS linter in a modern frontend project, choosing the right stylelint configuration is critical for consistent code style, maintainability, and team alignment. The four packages — stylelint-config-prettier, stylelint-config-recommended, stylelint-config-sass-guidelines, and stylelint-config-standard — each serve distinct roles in the linting pipeline. Let’s break down what they do, how they differ, and how to combine them effectively.

🧩 Core Purpose: What Each Package Actually Does

stylelint-config-recommended

This package disables rules that are known to cause false positives or overlap with other tooling (like CSS parsers). It enables only rules that catch real errors — such as invalid hex colors, unknown properties, or duplicate selectors.

// .stylelintrc.json using only recommended
{
  "extends": ["stylelint-config-recommended"]
}

It does not enforce stylistic preferences (like indentation or quote style). Think of it as the minimal safety net.

stylelint-config-standard

This extends stylelint-config-recommended and adds a comprehensive set of stylistic rules based on common community conventions. It enforces things like:

• Consistent spacing around colons and braces
• Alphabetical ordering of properties
• Disallowing vendor prefixes unless needed

// .stylelintrc.json using standard
{
  "extends": ["stylelint-config-standard"]
}

Because it builds on recommended, you don’t need to include both — standard already includes all error-catching rules.

stylelint-config-prettier

This package disables all stylelint rules that might conflict with Prettier. It doesn’t enable any rules itself — it only turns off overlapping ones (like those controlling line breaks, spacing, or quotes).

// .stylelintrc.json combining standard + prettier
{
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-prettier"
  ]
}

⚠️ Important: stylelint-config-prettier must be listed last so it can override conflicting rules from other configs.

stylelint-config-sass-guidelines

This config enforces the official Sass Guidelines — a popular style guide for SCSS/Sass projects. It includes rules for:

• Naming conventions (e.g., $variable-name in kebab-case)
• Nesting depth limits
• Use of !default flags
• File structure and imports

// .stylelintrc.json for a Sass project
{
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-sass-guidelines"
  ]
}

Note: This config assumes you’re using SCSS or Sass syntax. It may produce irrelevant warnings in plain CSS projects.

🔀 How They Work Together (or Don’t)

These configs are designed to be composable, but not all combinations make sense.

✅ Valid Combinations

• stylelint-config-standard + stylelint-config-prettier: Common in modern JS/CSS projects using Prettier.
• stylelint-config-recommended + stylelint-config-sass-guidelines: Minimal error checking plus Sass-specific style rules.
• stylelint-config-standard + stylelint-config-sass-guidelines: Full stylistic enforcement for SCSS projects (no Prettier).

❌ Redundant or Conflicting Combos

• stylelint-config-recommended + stylelint-config-standard: Redundant — standard already includes recommended.
• stylelint-config-sass-guidelines + stylelint-config-prettier without standard or recommended: Leaves basic CSS validation unenforced.

🛠️ Real-World Setup Examples

Scenario 1: React App with CSS Modules + Prettier

You want Prettier to handle formatting, and stylelint to catch bugs only.

{
  "extends": [
    "stylelint-config-recommended",
    "stylelint-config-prettier"
  ]
}

Here, recommended catches real issues; prettier disables any stylistic rules that would fight Prettier.

Scenario 2: Design System Using SCSS (No Prettier)

Your team follows Sass Guidelines strictly and wants full stylistic enforcement.

{
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-sass-guidelines"
  ],
  "rules": {
    "max-nesting-depth": 3
  }
}

This gives you base CSS standards plus Sass-specific conventions.

Scenario 3: Legacy Project Migrating to Prettier

You’re introducing Prettier to an existing codebase that uses stylelint-config-standard.

{
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-prettier"
  ]
}

Running stylelint --fix after this change will remove stylelint-enforced formatting, letting Prettier take over.

⚠️ Critical Notes on Maintenance and Scope

• stylelint-config-prettier is actively maintained and safe to use. It only disables rules — it never enables them.
• stylelint-config-recommended and stylelint-config-standard are official stylelint configs, updated alongside stylelint core.
• stylelint-config-sass-guidelines is community-maintained. As of the latest release, it supports modern stylelint versions and SCSS syntax via postcss-scss. Always verify compatibility if using non-standard preprocessors.

None of these packages are deprecated. However, stylelint-config-sass-guidelines should only be used in Sass/SCSS projects — applying it to plain CSS will trigger irrelevant rules (e.g., about @mixin usage).

📊 Summary Table

¹ It assumes error checking is handled by another config (like recommended).

• Requires pairing with stylelint-config-prettier to be Prettier-safe.

💡 Final Recommendation

• Start with stylelint-config-recommended if you only want bug detection.
• Use stylelint-config-standard if your team wants consistent CSS style without Prettier.
• Add stylelint-config-prettier last whenever Prettier is in your toolchain.
• Reach for stylelint-config-sass-guidelines only if you’re writing SCSS and want to follow the Sass Guidelines project.

Most professional teams end up with one of two setups:

1. Prettier + minimal stylelint: recommended + prettier
2. Stylelint-only styling: standard (+ sass-guidelines if using SCSS)

Avoid mixing all four — it leads to confusion and redundant rules. Keep your linting strategy simple, intentional, and aligned with your formatting toolchain.