stylelint: Error with scss nested property syntax

With the following code (using gulp-stylelint and syntax: 'scss'):

.test {
  margin: {
    left: auto;
    right: auto;
  }
}

I get the error:

events.js:141
      throw er; // Unhandled 'error' event
      ^
Error: Expected pseudo-class or pseudo-element
    at new error (…/node_modules/postcss-selector-parser/dist/processor.js:27:23)
    at Parser.error (…/node_modules/postcss-selector-parser/dist/parser.js:218:15)
    at Parser.pseudo (…/node_modules/postcss-selector-parser/dist/parser.js:316:25)
    at Parser.parse (…/node_modules/postcss-selector-parser/dist/parser.js:533:22)
    at Parser.loop (…/node_modules/postcss-selector-parser/dist/parser.js:501:18)
    at new Parser (…/node_modules/postcss-selector-parser/dist/parser.js:93:21)
    at Processor.process (…/node_modules/postcss-selector-parser/dist/processor.js:24:21)
    at Plugin.<anonymous> (…/node_modules/stylehacks/dist/plugins/bodyEmpty.js:36:67)
    at Plugin.<anonymous> (…/node_modules/stylehacks/dist/plugin.js:40:29)
    at …/node_modules/postcss/lib/container.js:81:26

Wondering if anyone can point me in the right direction, of why this might be happening.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

Our internal utils would help us ignore nonstandard selectors like this (ending in a 😃, but stylehacks doesn’t have the same safeguards.

For anyone wishing to tackle this upstream in stylehacks, perhaps start with adding this safeguard to each of stylehacks’s plugin. And then seeing what mileage that gets you.

but it would be nice to have a rule, that would check for this [use of nested properties], as I’d like to avoid it in the codebase I’m working on.

@s10wen That’s a great suggestion for the stylelint-scss plugin pack developers. I recommend creating an issue in their repo for a new rule called declaration-nested-properties: "always"|"never", which would require or disallow allow the use of nested properties within declarations. I’m sure they’d welcome you contributing the rule too.

@s10wen As an aside, one of the advantages of crafting your own CSS Processor with PostCSS is that you don’t need to rely on linting to disallow language features. Instead, you simply don’t use the postcss-nested-props PostCSS plugin within your pipeline, which makes the feature unavailable to your team. Powerful stuff right there 😃