Version 1.2.0 breaks complex multiline expressions

[joakimkemeny]

Let's say I have some styles with a switch statement that Prettier formats like this:

const Test = styled.div`
  background-color: ${props => {
    switch (p.type) {
      case "success":
        return "green"
      case "danger":
        return "red"
      default:
        return "blue"
    }
  }};
`

This was fine before 1.2.0 but in 1.2.0 I get the following errors:

• Expected no more than 0 empty lines
• Expected newline after ":" with a multi-line declaration

[emilgoldsmith]

@chinesedfan could you look at this as it seems to relate to your multiline interpolation PR?

Also @joakimkemeny if you could please share the version of all the relevant packages (stylelint specifically) and your stylelint config

[joakimkemeny]

I use the latest version of these libs (I found this problem as I was updating all dependencies):

• styled-components: 3.0.1
• stylelint: 8.4.0
• stylelint-config-standard: 18.0.0
• stylelint-config-styled-components: 0.1.1
• stylelint-processor-styled-components: 1.2.0 (I tried later version, this is where it broke)

My stylelint config is really simple:

{
  "processors": ["stylelint-processor-styled-components"],
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-styled-components"
  ],
  "rules": {
    "no-descending-specificity": null
  },
  "syntax": "scss"
}

[chinesedfan]

@emilgoldsmith Confirmed they were introduced by 1.2.0.

Expected no more than 0 empty lines

Our new substitution method will convert the multi-line interpolation to comments, but stylelint treated comments as empty strings in value. Maybe we should filter these warnings as well as indentations.

Expected newline after ":" with a multi-line declaration

The old substitution just kept one line so no warnings before. But I think the current implementation is more reasonable. Because it is really a multi-line declaration, even written in interpolation.

[emilgoldsmith]

Hmm, I don't think we can filter here though, as it would be overkill and remove a lot of valid errors.

What about instead of comments we just put in dummy css. Such as -styled-mixin: $dummyVariable. That should work right? Or are there any issues with that?

[chinesedfan]

it would be overkill and remove a lot of valid errors

We have interpolationLines records which lines are interpolations, so it can be used to avoid removing valid errors.

What about instead of comments we just put in dummy css. Such as -styled-mixin: $dummyVariable

Comments are not the best dummy css. But as discussed in #140, it is still hard to replace with -styled-mixin: $dummyVariable without introducing more lint errors.

[edahlseng]

What's the latest status on this issue (I'm not familiar with the codebase, and so I'm not following the discussion here...)? The problem still exists in v1.3.1.

[emilgoldsmith]

No one has yet to take on solving the issue, @edahlseng feel free to be the one to do it

[edahlseng]

@emilgoldsmith, I'm happy to take a look at solving, but I'm completely new to the codebase. Do you have any recommendations on where a good place to start looking may be?

[chinesedfan]

Thanks @edahlseng! You can take a look at #140 to get some inspirations. If still have questions, feel free to ask us.

[caribou-code]

Just wondering if there's any progress with this? I have these linting errors in version 1.3.2 and not sure how to get around it with either disabling the rules globally or disabling them for a file/line which doesn't feel right.

[chinesedfan]

@caribou-code Can you try #220 locally? I hope more people can help me test the fix.