prettier: CSS: Prettier wrongly adds new semicolons to at-rule preludes

Input:

@a b({"c": d}) {}

Output:

@a b( {
  "c":d ;
}
) {
}

Expected behavior:

What’s breaking things is that Prettier is introducing a totally new ; character after the d that previously didn’t exist anywhere. I’m not sure why it does this, but it’s causing enough breakage that I’m going to have to disable Prettier in some workflows unless/until this is fixed.

Note: this doesn’t seem to be a PostCSS parsing error - you can easily generate a PostCSS parsing error with input like a { --a: {a} } - my example above seems to be parsable by PostCSS but broken in Prettier, and so that’s why I’m reporting here instead of to PostCSS

Also, if it helps, this is not problematic: @a b({c: d}) {}, but when you make either of those innermost tokens into a string (e.g. @a b({"c": d}) {} or @a b({c: "d"}) {}) Prettier seems to have an issue.

Thanks!

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 1
Comments: 17 (10 by maintainers)

Most upvoted comments

@tomhodgins What kind of toxic communication? I just asked a question and asked for a real example so that we could better think on bug fix

alexander-akait on May 1, 2020

I think it violates CSS spec

What makes you say that @evilebottnawi? Can you be more specific about which part exactly you think is invalid, and why you think it’s invalid, and what valid code would look like instead? Please be as specific as you can! The examples I showed are parsable using the syntax described by the CSS Syntax Spec.

Can you provide real use case?

As for real-world use cases there’s valid CSS syntax out there that works in all browsers today, and can be parsed correctly according to CSS syntax, but that will break if simply passed through Prettier because of this issue.

Here’s an example of a stylesheet that’s 100% valid CSS, parsable by browsers, and includes some rules that suffer from this particular bug. Here’s one of those rules:

@supports (--element(".minwidth", {"minWidth": 300})) {
  [--self] {
    background: greenyellow;
  }
}

You can test how well your own browsers can parse this syntax here:

Why is Prettier going beyond formatting, and modifying and inserting characters where they didn’t exist in the original input?

If you want some AST dumps from parsing these productions as CSS according to the CSS Syntax spec I’ve included some examples below:

@a b({c: d}) {}

{
  "type": "STYLESHEET",
  "value": [
    {
      "type": "AT-RULE",
      "value": {
        "type": "BLOCK",
        "value": [],
        "name": "{"
      },
      "name": "a",
      "prelude": [
        {
          "token": "WHITESPACE"
        },
        {
          "type": "FUNCTION",
          "value": [
            {
              "type": "BLOCK",
              "value": [
                {
                  "token": "IDENT",
                  "value": "c"
                },
                {
                  "token": ":"
                },
                {
                  "token": "WHITESPACE"
                },
                {
                  "token": "IDENT",
                  "value": "d"
                }
              ],
              "name": "{"
            }
          ],
          "name": "b"
        },
        {
          "token": "WHITESPACE"
        }
      ]
    }
  ]
}

@a b({"c": d}) {}

{
  "type": "STYLESHEET",
  "value": [
    {
      "type": "AT-RULE",
      "value": {
        "type": "BLOCK",
        "value": [],
        "name": "{"
      },
      "name": "a",
      "prelude": [
        {
          "token": "WHITESPACE"
        },
        {
          "type": "FUNCTION",
          "value": [
            {
              "type": "BLOCK",
              "value": [
                {
                  "token": "STRING",
                  "value": "c"
                },
                {
                  "token": ":"
                },
                {
                  "token": "WHITESPACE"
                },
                {
                  "token": "IDENT",
                  "value": "d"
                }
              ],
              "name": "{"
            }
          ],
          "name": "b"
        },
        {
          "token": "WHITESPACE"
        }
      ]
    }
  ]
}

@a b({c: "d"}) {}

{
  "type": "STYLESHEET",
  "value": [
    {
      "type": "AT-RULE",
      "value": {
        "type": "BLOCK",
        "value": [],
        "name": "{"
      },
      "name": "a",
      "prelude": [
        {
          "token": "WHITESPACE"
        },
        {
          "type": "FUNCTION",
          "value": [
            {
              "type": "BLOCK",
              "value": [
                {
                  "token": "IDENT",
                  "value": "c"
                },
                {
                  "token": ":"
                },
                {
                  "token": "WHITESPACE"
                },
                {
                  "token": "STRING",
                  "value": "d"
                }
              ],
              "name": "{"
            }
          ],
          "name": "b"
        },
        {
          "token": "WHITESPACE"
        }
      ]
    }
  ]
}

If you diff these parsed AST’s (the result of the algorithm described in the CSS syntax spec as Parse a Stylesheet the only difference between d and "d" is that one is an ident token and the other is a string token.

Is there anything more I can provide to illustrate that Prettier has a legitimate issue handling CSS syntax here?

tomhodgins on May 1, 2020