Managing Compatibility with Browserslist

The web pages we develop need to run on various browsers, and different browsers and versions all have slight differences in page parsing. If it’s IE, it’s even more troublesome. At one time, frontend developers would groan when talking about IE compatibility, cursing IE countless times in their hearts.

How to elegantly handle compatibility issues is a constant challenge. Now there are relatively systematic solutions to this problem, which I’ll document here.

Note: Different scenarios and habits lead to different configuration methods. Here I’ll explain based on my personal practice, for reference only.

Browserslist

Configuration

Create a .browserslistrc file in the project root directory and write down the target browser range according to your requirements. For example, my configuration is as follows:

# Browsers that we support
last 1 years

Meaning: Support browsers and versions from the last year.

For specific Browserslist configuration syntax, click here

Testing

After configuration, execute the following command in the terminal to get the list of target browser versions:

$ npx browserslist

Note

• Browserslist only provides a mechanism to conveniently set and retrieve target browsers and their versions

• Actual compatibility handling still requires other tools to detect and fix based on the browser list

Below, continue with installation and configuration.

eslint-plugin-compat

Installation

$ yarn add eslint-plugin-compat -D

Configuration

Add the following configuration to .eslintrc.js:

module.exports = {
  root: true,
  extends: [
    'plugin:compat/recommended'
  ],
  rules: {
    'compat/compat': ['error'],
  }
};

Run eslint src/main/webapp/**/*.{ts,tsx} --quiet to perform compatibility detection based on target browsers. If there are errors, they will be displayed.

Since my browser support above is quite modern, compatibility issues aren’t likely to appear. For example, if I change my browser list to last 10 years, then errors will appear:

Note

eslint-plugin-compat mainly focuses on WEB API and doesn’t check ES API. Therefore, other Lint plugins are needed to detect ES API compatibility.

eslint-plugin-es

This plugin is designed for ES detection. For example, lookbehind assertions in ES9 are not supported by Safari, so we need to add corresponding rules to block this usage.

Installation

For example, to block lookbehind assertions, the following configuration is needed:

$ yarn add es/no-regexp-lookbehind-assertions -D

Configuration

Add the following rule to .eslintrc.js:

'es/no-regexp-lookbehind-assertions': ['error']

CSS

CSS issues are similar to JS, but CSS itself won’t cause page white screens, only some styles that don’t work. At the same time, postcss can generate specified CSS syntax for target browsers.

Installation

$ yarn add postcss-loader -D

$ yarn add stylelint-no-unsupported-browser-features -D

$ yarn add obsolete-webpack-plugin -D

Configuration

Add the following configuration to .stylelintrc.json:

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

Add configuration to Webpack:

{
          test: /\.css$/,
          use: [
            'postcss-loader'
          ]
        }

1. When executing the stylelint command stylelint src/main/webapp/**/*.less --syntax=less, it can detect style support in target browsers
2. postcss automatically adds some compatible style syntax to ensure styles work in target browsers

obsolete-webpack-plugin

When a page is not supported, it sometimes shows a blank screen, which is a terrible user experience. Therefore, detection scripts can be added to alert users, and this plugin solves this problem.

Installation

$ yarn add obsolete-webpack-plugin -D

Configuration

plugins: [new ObsoleteWebpackPlugin()]

Testing

After packaging, an obsolete.js script file will be generated, and index.html will include this JS.

Conclusion

• As shown above, we can effectively manage frontend browser compatibility.
• If the target browser and version range changes, all you need to do is modify browserslist => detect JS, CSS => fix according to error prompts.

References

• https://watofundefined.dev/posts/regexp-lookbehinds-bit-me-in-the-behind/