Sometimes users who are familiar with other languages forget that Sass doesn't need parentheses around its conditionals (as in, @if (...) {, or @else if (...) {, or @while (...) {). The linter should suggest that these parentheses be removed.

Sass allows either underscores or hyphens to be used interchangeably as identifier separators, but hyphens are preferred as they match CSS's own naming conventions. We should have a lint for any Sass identifier (variable, mixin, function, or placeholder name) that complains about underscores and suggests using hyphens instead.

A mistake we see occasionally is users using unquoted strings as map keys, having one of those keys be named something like blue, and getting confused later on when that key compiles to #00f instead. We should add a lint rule to help out with this.

The most conservative way to do this is probably to warn the user when a map:

• contains an unquoted string key,
• contains a color name key, and
• contains only unquoted string or color name keys.

Less conservatively, we could also warn about maps that have keys of mixed type in general or maps with any unquoted string keys, although this risks having more false positives.

A handful of built-in Sass functions adjust colors in a way that subtly fails to meet user expectations. They add/subtract numbers to/from the colors' properties rather than fluidly scaling them towards the max/min value, which can clip colors to the maximum or minimum values. For example, darken($color, 30%) will return black for every color with lightness 30% or lower.

The scale-color() function behaves much more intuitively. It fluidly scales properties, so that for example scale-color($color, $lightness: -30%) will always return a darker color but will never return black unless the input is already black. Unfortunately, the other functions are older and have more obvious names, so users tend to gravitate towards them. A lint would help steer people away.

The functions that should have this lint are saturate(), desaturate(), darken(), lighten(), opacify(), fade-in(), transparentize(), and fade-out().

The quote() function is never necessary when the argument is already a quoted string, and the unquote() function is never necessary immediately within interpolation. I've seen these mistakes appear in the wild, so it would be good to add lints for them.

Need to implement a lint rule that reports style rules that are too deep, in terms of Sass nesting (not selector specificity):

p.foo {
  .bar {
    .error {
      .severe { // LINT
        color: red;
      }
    }
  }
}

This is similar to scss-lint's NestingDepth.

I tried running the linter, but it fails on my machine:

~/github/linter/$ pub get
Resolving dependencies... 
The current Dart SDK version is 2.1.0.
Because sass_linter requires SDK version >=1.22.0 <2.0.0, version solving failed.

I wonder, maybe this needs just a config change in pubspec.yaml?

(FWIW, I tried this, and then it says: Because sass_linter depends on test >=0.12.0-beta.3 <1.3.0 which requires SDK version >=1.8.0 <2.0.0-∞, version solving failed. - so it looks like there's more work to be done.)

It's generally a bad practice to use unquoted strings as map keys. Some tokens (like green) parse as colors rather than strings, which means that if the keys are used in selector names, they won't necessarily emit as text (for example, green is emitted as #0f0 in compressed mode). It would be good to have a lint that encourages users to quote their map keys.

A pattern I see occasionally is:

@each $key in map-keys($map) {
  $value: map-get($map, $key);
  // ...
}

This is an unnecessarily verbose way of writing:

@each $key, $value in $map {
  // ...
}

There are also some legitimate cases where only the key is used, so maybe it's a good idea to look for the pattern map-get($map, $key) in the loop body before raising the lint?

Need to implement a lint rule that reports empty rules.

.foo {
  .bar {
    color: red;
    .baz {}  // LINT
}

This is similar to scss-lint's EmptyRule.

Need to implement a lint rule that reports unnecessary parent references:

p {
  & > .foo {
    ...
  }
}

This is similar to scss-lint's UnnecessaryParentReference.

Because null in Sass is falsey, users should treat it as a boolean rather than explicitly checking for it. For example, @if index(...) { ... } is preferable to @if index(...) != null { ... }.

Users who don't fully understand how Sass's unit arithmetic works will often write code like #{$var}px in an attempt to add units to a number. However, this produces an unquoted string rather than an actual numeric value, which means it won't work with arithmetic or Sass functions. It would be good to provide a lint that suggests they write $var * 1px instead and that links to documentation on how number arithmetic works.

Right now, the linter only parses files that use the SCSS syntax. It should detect if files have the .scss syntax, and use the indented syntax parser for them. Both syntaxes produce the same AST, so it should be relatively easy to support both.

Add a lint rule for CSS variables defined using un-interpolated Sass variables. Recent versions of Sass require that you to use interpolation when including Sass variables to maintain maximal CSS compatibility.

$n: 255;
--color: $n, $n, $n; // LINT

$n: 255;
--color: #{$n}, #{$n}, #{$n}; // OK

See this blog post for more details: http://sass.logdown.com/posts/809572

Need to implement a lint rule that reports unknown rules that start with @:

@warn("Hello.");    // OK
@warning("Hello."); // LINT

This is similar to stylelint's at-rule-no-unknown.

Because interpolation is necessary to include SassScript values in many contexts, users sometimes accidentally use it in SassScript expressions themselves. For example, see this line from Angular's Material Design components. Not only is this unnecessary, it coerces the result of the expression to an unquoted string, which may make it fail with further mathematical operations down the line.

There should be a lint for this. Specifically, if an interpolated identifier that's just a single interpolation with no other text is encountered, the linter should suggest the user replace it with the value of the expression.

Need to implement a lint rule that reports import paths that do not fit the brief, human-readable style. Namely, underscores and file suffixes are unnecessary.

@import "partials/_colors.scss";  // LINT
@import "partials/_colors";       // LINT
@import "partials/colors.scss";   // LINT

@import "partials/colors";        // OK

This is similar to scss-lint's ImportPath.