`block-no-empty` false positive

[vincentducorps]

When we only have interpolation(s) in a block we have an error: Unexpected empty block block-no-empty

    &:hover {
      ${props => colorHoverMixin(props)}
    }

    &:hover {
      ${props => colorHoverMixin(props)}
      ${props => otherMixin(props)}
    }

    && {
      ${props => doSomething(props)}
    }

[hudochenkov]

It's a problem with the Stylelint rule. Could you report a bug in its repository, please? There we could find what action to take.

I suggest to disable the rule temporary until solution is found.

[johnnybenson]

Here's another exotic example that we may perhaps consider a false positive, because a styled-component has utility despite having an empty block., e.g. extending from a base.

const Base = styled.span.attrs({ children: ['🍕'] })``;

const Extended = styled(Base)` 
    font-size: 100000000px;
`;

Disabling the rule for now, thanks!

[hudochenkov]

@johnnybenson I see some over-engineering :)

Stylelint only concerns about stuff between backticks. Of course, we could change postcss-styled-syntax to provide info to CSS piece if styled component has attrs attribute. And create Stylelint rule specifically for postcss-styled-syntax to read that information and don't report block as empty. However, I think it is too much overhead, and value provided is not worth spent time.

Also I would recommend to create actual React component instead of making styled component like Base, as it would be more performant and easier to understand.

[johnnybenson]

Eh my example was made up / convoluted! Makes sense for the linter to only care about what is between the back ticks. Thanks for sharing your thoughts :)

[ghost]

Not sure if this is better than disabling the rule or not, but adding / a comment / inside the not-really-empty block seems to un-empty it.

[hudochenkov]

The fix will be released in the next Stylelint version.