Bugs and OS-specific inconsistencies in LSP notifications/responses

[SCWells72]

I'm seeing very odd and inconsistent results from SLDS Validator 2.0.12 that seem to vary based on the host operating system.

Example 1

I'll use productCard.css LWC component from the ebikes-lwc project, but I'll simplify it to the following to minimize the LSP notifications/responses:

section {
    font-weight: bold;
    font-size: 0.85rem;
    margin-top: 0.75rem;
    text-transform: uppercase;
}

On Windows, I get the following text/publishDiagnostics notification:

{
  "uri": "file:///C:/dev/path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.css",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 0,
          "character": 0
        },
        "end": {
          "line": 0,
          "character": 0
        }
      },
      "severity": 1,
      "code": "UTILITY_CLASS",
      "source": "SLDS",
      "message": "Consider using a utility class:\r\n\"slds-m-top_small\"\r\n\"slds-var-m-top_small\"\r\n"
    }
  ]
}

and textDocument/codeAction response (truncated to include only one quickfix):

[
  {
    "title": "Update to utility class \u0027slds-m-top_small\u0027",
    "kind": "quickfix",
    "diagnostics": [
      {
        "range": {
          "start": {
            "line": 0,
            "character": 0
          },
          "end": {
            "line": 0,
            "character": 0
          }
        },
        "severity": 1,
        "code": "UTILITY_CLASS",
        "source": "SLDS",
        "message": "Consider using a utility class:\r\n\"slds-m-top_small\"\r\n\"slds-var-m-top_small\"\r\n"
      }
    ],
    "edit": {
      "changes": {
        "file:/C:/path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.html": [
          {
            "range": {
              "start": {
                "line": 33,
                "character": 28
              },
              "end": {
                "line": 33,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          },
          {
            "range": {
              "start": {
                "line": 43,
                "character": 28
              },
              "end": {
                "line": 43,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          },
          {
            "range": {
              "start": {
                "line": 51,
                "character": 28
              },
              "end": {
                "line": 51,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          }
        ],
        "file:///C:/path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.css": [
          {
            "range": {
              "start": {
                "line": 0,
                "character": 0
              },
              "end": {
                "line": 0,
                "character": 0
              }
            },
            "newText": ""
          }
        ]
      }
    }
  }
]

On Mac and Linux, I get the following text/publishDiagnostics notification:

{
  "uri": "file:///path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.css",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 3,
          "character": 4
        },
        "end": {
          "line": 3,
          "character": 24
        }
      },
      "severity": 1,
      "code": "UTILITY_CLASS",
      "source": "SLDS",
      "message": "Consider using a utility class:\n\"slds-m-top_small\"\n\"slds-var-m-top_small\"\n"
    }
  ]
}

and textDocument/codeAction response (truncated in the same manner):

[
  {
    "title": "Update to utility class \u0027slds-m-top_small\u0027",
    "kind": "quickfix",
    "diagnostics": [
      {
        "range": {
          "start": {
            "line": 3,
            "character": 4
          },
          "end": {
            "line": 3,
            "character": 24
          }
        },
        "severity": 1,
        "code": "UTILITY_CLASS",
        "source": "SLDS",
        "message": "Consider using a utility class:\n\"slds-m-top_small\"\n\"slds-var-m-top_small\"\n"
      }
    ],
    "edit": {
      "changes": {
        "file:///path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.html": [
          {
            "range": {
              "start": {
                "line": 33,
                "character": 28
              },
              "end": {
                "line": 33,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          },
          {
            "range": {
              "start": {
                "line": 43,
                "character": 28
              },
              "end": {
                "line": 43,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          },
          {
            "range": {
              "start": {
                "line": 51,
                "character": 28
              },
              "end": {
                "line": 51,
                "character": 28
              }
            },
            "newText": " class\u003d\"slds-m-top_small\""
          }
        ],
        "file:///path/to/ebikes-lwc/force-app/main/default/lwc/productCard/productCard.css": [
          {
            "range": {
              "start": {
                "line": 3,
                "character": 4
              },
              "end": {
                "line": 3,
                "character": 24
              }
            },
            "newText": ""
          }
        ]
      }
    }
  }
]

There are two important differences to note there:

1. In the Windows textDocument/publishDiagnostics notification, the Position values for the CSS file are [0, 0] whereas on Mac/Linux, they're the correct coordinates of the reported diagnostics. Note that this is happening in this specific example but not pervasively as there are many other examples where Position values are reported -- at least on Windows -- as [0, offset] instead of [line, character] as reported in Position values reported by the language server don't conform with the LSP spec #141.
2. In the textDocument/codeAction responses, the edit ranges are effectively empty, e.g., [43, 28] ~ [43, 28]. Again, this is not a pervasive issue, but I do see it happening in a decent set of files. Obviously this results in an incorrect file state when the edits are applied.

Example 2

I'l provide another example that shows both inconsistency across OSes and what seems to be a bug from the lwc-recipes project for the file apiMethod.css.

On Windows, the textDocument/publishDiagnostics notification is (again, truncated to show the key aspects):

{
  "uri": "file:///C:/path/to/lwc-recipes/force-app/main/default/lwc/apiMethod/apiMethod.css",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 0,
          "character": 60
        },
        "end": {
          "line": 0,
          "character": 67
        }
      },
      "severity": 3,
      "code": "WCAG",
      "source": "SLDS",
      "message": "Consider replacing \"#ecebea\" with an updated design token:\r\n\"--slds-g-color-neutral-base-90\": \r\n\"--slds-g-color-palette-neutral-90\": \r\n"
    },
    {
      "range": {
        "start": {
          "line": 0,
          "character": 137
        },
        "end": {
          "line": 0,
          "character": 141
        }
      },
      "severity": 3,
      "code": "DESIGN_TOKEN",
      "source": "SLDS",
      "message": "Consider replacing \"14px\" with an updated design token:\r\n\"squareIconMediumContentAlt\": Alternate medium tap target size\r\n"
    }
  ]
}

On Mac/Linux, the notification is:

{
  "uri": "file:///path/to/lwc-recipes/force-app/main/default/lwc/apiMethod/apiMethod.css",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 1,
          "character": 50
        },
        "end": {
          "line": 1,
          "character": 57
        }
      },
      "severity": 3,
      "code": "WCAG",
      "source": "SLDS",
      "message": "Consider replacing \"#ecebea\" with an updated design token:\n\"--slds-g-color-neutral-base-90\": \n\"--slds-g-color-palette-neutral-90\": \n"
    },
    {
      "range": {
        "start": {
          "line": 4,
          "character": -1
        },
        "end": {
          "line": 4,
          "character": 3
        }
      },
      "severity": 3,
      "code": "DESIGN_TOKEN",
      "source": "SLDS",
      "message": "Consider replacing \"14px\" with an updated design token:\n\"squareIconMediumContentAlt\": Alternate medium tap target size\n"
    }
  ]
}

Again, there are two important aspects to note:

1. In the Windows textDocument/publishDiagnostics notification, the Position values are reported as [0, offset] whereas on Mac/Linux they're reported as [line, character]. Again, this is exactly what has already been reported in Position values reported by the language server don't conform with the LSP spec #141, but this serves as a perfect example of it happening.
2. Perhaps more importantly, though, is that on Mac/Linux, a value for range > start > character has been reported as -1. That will lead to the wrong range being highlighted at best depending on the behavior of the LSP client.

Okay. I think that provides concrete, (hopefully) reproducible examples of these issues. Please let me know if I can provide any further information or details.