Customise StyleLint's syntax for a given file type

[jackfranklin]

We use TypeScript files to define web components that use LitHtml. By default Stylelint assumes that TS files use Styelint's css-in-js syntax setting, but that fails to find any of the CSS we have defined in our TypeScript files.

If we could customise the stylelint.syntax setting per file type, this would resolve the problem:

"[typescript]": {
  "stylelint.syntax": "html"
}

Is this something you would consider ? I am happy to attempt the PR myself 👍

[jeddy3]

This sounds like a good suggestion. It would resolve the problem.

By default Stylelint assumes that TS files use Styelint's css-in-js syntax setting

Yep, that's the underlying issue. Stylelint should detect LitHTML components and set the syntax to "html" automatically. The bug is with postcss-syntax which Stylelint relies on for language detection. Unfortunately, the author of that package is no longer active on GitHub. However, there's work going on in the background to update the package (for PostCSS@8). This work is unlikely to land for a while, though, as it's complicated and not many people are interested in it.

This problem could also be solved by adding an overrides property to the configuration object, like so:

// .stylelintrc.js
{
  "syntax": "css-in-js",
  "rules": {
    "at-rule-no-unknown": true,
  },
  "overrides": [
    {
      "files": ["/lit-elements/*.ts"],
      "syntax": "html",
      "rules": {
         "at-rule-no-unknown": false,
      }
  ]
}

And having this extension respect that configuration.

No one has time to implement the overrides property yet.

Ideally the issue would be fixed in these places but it's more work. By adding your suggestion users can workaround these limitations, i.e. they can configure their CI using the CLI (npx stylelint "components/*.ts" --syntax html), and their VS Code editors using your suggested setting.

Thanks for the offer of a PR. That would be great! The two core maintainers of this package haven't had much time to dip in of late. If you know how to release VS Code extensions, I can give you the keys. Otherwise, I can look into the release process myself.

[jackfranklin]

@jeddy3 thanks for the reply; sorry for my delay in replying.

I'd love to look into the stylelint overrides but I don't know if I have the capacity to do that at the moment. As a stop gap, would you accept a PR to this repo that lets us override the config for the VS Code extension?

[jeddy3]

As a stop gap, would you accept a PR to this repo that lets us override the config for the VS Code extension?

Yes, absolutely.

The two core maintainers of this package haven't had much time to dip in of late. If you know how to release VS Code extensions, I can give you the keys to do that. Otherwise, I can look into the release process myself once your pull request is merged.

[adalinesimonian]

Extension-side, the solution for this is resource-scoped configuration, which is effectively what #271 is about (I might rename that issue). That's going to take quite a bit of refactoring to change the way we work with configuration objects in the extension, so I can't guarantee when that'll be implemented. In the meantime, using overrides is really your best option. The effective equivalent of the configuration in your initial example is:

// .stylelintrc.js or similar
module.exports = {
  // …
  overrides: [
    {
      files: ['**/*.ts', '**/*.tsx'], // what files the additional configuration should apply to
      customSyntax: 'postcss-html', // the syntax module to be used
    }
  ],
}

[jeddy3]

@jackfranklin FYI, the overrides configuration property was added in 14.0.0 of Stylelint.