npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

stylelint-no-unsupported-browser-features

v8.0.2

Published

Disallow features that are unsupported by the browsers that you are targeting

Downloads

1,003,878

Readme

stylelint-no-unsupported-browser-features

npm version ci codecov semantic-release

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

screenshot

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.

Installation

$ 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

Usage

  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

Options

  • 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
    }]
  }
}

Recommendations

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

Known issues

  • 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.

License

MIT