Thanks for the suggestion. I'm not sure how to go about doing this for this plugin.

Stylelint is built on PostCSS, so it's easy for them to work with PostCSS plugins. This plugin is based on CSSTree, which means there's no easy path to supporting PostCSS plugins. I'm not saying it's impossible, just that there would have to be a different as-yet-unknown approach.

I'm not very familiar with the differences between CSS and SCSS, can you provide a high-level overview?

And have you tried using the tolerant: true option? What happens if you do that?

SCSS provides a handful of syntax/features on top of base CSS, such as:

• nesting
• variables
• mixins/functions

ex:

$primary-color: blue;
$secondary-color: white;

.button {
  background-color: $primary-color;
  color: $secondary-color;

  &:hover {
    background-color: darken($primary-color, 10%);
  }
}

Changing to tolerant: true does seem to allow some of the linting, so that's great, but in my eslint.config.mjs file I'm seeing the following error from the TS service:

Object literal may only specify known properties, and 'tolerant' does not exist in type 'LanguageOptions'.ts(2353)

{
  files: ["**/*.css", "**/*.scss"],
  plugins: {
    css,
  },
  language: "css/css",
  languageOptions: {
    tolerant: true,
  },
  rules: {
    "css/prefer-logical-properties": "error",
  },
},

Thanks for the examples. I'm not sure the best way to look at this. It could be a custom parser or maybe some changes to CSSTree. It will take me some time to investigate.

Object literal may only specify known properties, and 'tolerant' does not exist in type 'LanguageOptions'.ts(2353)

Thanks for pointing this out. It looks like this is an error in the types coming from the eslint package. I'll dig into that.

+1! I would like to completely abandon the stylelint solution, but without sass/scss support (and there is also stylus), it is problematic to do so. But I believe that eslint/css has a great future!

@scripthunter7 I'm curious if, with your experience with CSSTree, if you think it's possible to extend it to parse SCSS?

@nzakas Actually, CSS Tree is quite modular and also supports the fork option, so I wouldn’t rule out the possibility of adapting it for SCSS as well

Okay, I think I have an idea of how to do this. Here's what I'm working on:
#112

You can follow along with the progress on the PR and give it a try. (Note: linting and type checking is currently failing. That's expected at this point.)

Okay, I severely underestimated the amount of effort this would take. The syntax surface area of SCSS is pretty large and it will likely take me a long time to work through every piece of it.

At this point, I'm looking for a company or person willing to sponsor development of an SCSS parser for this plugin.

A way to shortcut this effort could be to not write your own parser for SCSS and instead pull in postcss and postcss-scss plugins directly.

• https://github.com/postcss/postcss-scss
• stylelint-config-recommended-scss

Thanks for the suggestion. That would eliminate some of the work. It's still going to be a lot of work because we need to translate the AST into a format that this plugin would understand. As I mentioned, SCSS syntax surface area is quite large and needing to define and test AST nodes that won't interfere with what this plugin does is a large effort. I don't have enough free time to do that and also the other work that ESLint requires.

If someone else wants to take that on, I'd say go for it. For me, I can't afford to spend that much time on it without being paid.

Another option could be using the Sass parser being built into dart-sass- https://github.com/sass/dart-sass/tree/main/pkg/sass-parser. I'm not sure if that gets you further than the postcss-scss package, though.

Thanks for the suggestion, I'll take a look.

At least my initial impression is that we'd still really need a CSSTree-based approach in order to use the CSSTree validation utilities, which otherwise wouldn't know about SCSS syntax.

Marking it as accepted since there's an ongoing PR for this.

I took another look at this and I think there's a way we can use sass-parser as the parser and still use CSSTree validation. Basically, we'd need to still provide a complete syntax definition for CSSTree to be able to validate the AST. The downside is I don't see a way for things like no-invalid-properties to validate property values because it would require understanding the SCSS variables and be able to swap it out.

Overall, I think this work needs to take place outside of this plugin.