disallow features that aren't supported by your target browser audience

This plugin checks if the CSS you're using is supported by the browsers you're targeting. It uses doiuse to detect browser support. Doiuse itself checks your code against the caniuse database and uses browserslist to get the list of browsers you want to support. Doiuse and this plugin are only compatible with standard css syntax, so syntaxes like scss, less and others aren't supported.

$ npm install stylelint-no-unsupported-browser-features

Stylelint is a peerdependency of this plugin, so you'll have to install stylelint as well:

$ npm install stylelint

1. Add "stylelint-no-unsupported-browser-features" to your stylelint config plugins array
2. Add "plugin/no-unsupported-browser-features" to your stylelint config rules
3. Enable the rule by setting it to true, or pass optional extra configuration

• browsers: optional. Accepts an array of browsers you want to support. For example ['> 1%', 'Last 2 versions']. See browserslist for documentation.
• ignore: optional. Accepts an array of features to ignore. For example: ['rem', 'css-table']. Feature names can be found in the error messages.
• ignorePartialSupport: optional, off by default. Accepts a boolean. When enabled:
  • Rules that only trigger partial violations will be ignored.
  • Rules that trigger both partial and full violations will only report on the full support violations.
  • Rules that trigger only full support violations will not be affected.

So for example, in a .stylelintrc:

{
  "plugins": ["stylelint-no-unsupported-browser-features"],
  "rules": {
    "plugin/no-unsupported-browser-features": [
      true,
      {
        "browsers": ["> 1%", "Last 2 versions"],
        "ignore": ["rem"],
        "ignorePartialSupport": true
      }
    ]
  }
}

This is a good rule to use with "warning"-level severity, because its primary purpose is to warn you that you are using features not all browsers fully support and therefore ought to provide fallbacks. But the warning will continue even if you have a fallback in place (it doesn't know); so you probably do not want this rule to break your build. Instead, consider it a friendly reminder to double-check certain spots for fallbacks.

Also, doiuse uses browserslist to get the list of browsers you want to support. Browserslist accepts a browserslist file at the root of your project with a list of browsers that you want to support. Since there are other projects that can use this file (like autoprefixer or eslint-plugin-compat) the simplest solution is to define your intended browser support in this file. There are a lot of different ways to define this list. Check out the browserslist documentation for more options.

For the above setup you could use the following config:

./.stylelintrc

{
  "plugins": ["stylelint-no-unsupported-browser-features"],
  "rules": {
    "plugin/no-unsupported-browser-features": [
      true,
      {
        "severity": "warning"
      }
    ]
  }
}

./browserslist:

> 5%
Last 2 versions

• Visual Studio Code users leveraging stylelint-no-unsupported-browser-features through the official stylelint extension will need to restart VSCode after making changes to their browserslist configuration file. It seems that either VSCode or the extension are causing browserlist config files to be cached and are not watching for changes in the file. If you are relying on the browsers property within the rules section of .stylelintrc you can ignore this issue. Changes to the browsers property are discovered immediately.

MIT