For some time now, "browserslist" has been popping up frequently, and it has become an indispensable tool in the frontend development environment. I suspect this is largely because Babel, a standout star project in the frontend world, adopted it. Since many projects use Babel, they indirectly or directly end up using browserslist as well. Honestly, it's great; I think it's a good tool. It seems likely to be used as the standard for defining browser environments for the foreseeable future.

I usually try not to write posts about things you can find in detail on official sites. However, I'll try to summarize just the essential points you can use right away.

What is Browserslist?

I'll keep the introduction short. Think of browserslist as a tool specifically extracted for the function of selecting browser options. If a program needs to handle different tasks based on the browser it's running in, it might take the supported browser environment as an option, right? Frontend development often requires such options or configurations. Browserslist isolates this recurring configuration feature, making it easy to define the browser environment and use it in code. By itself, it doesn't have any special functionality; it's a program meant to be used by other programs, like frameworks or build tools. In Babel, the required polyfills or the build output differs depending on the browser. Therefore, Babel needs to receive the target browser environment of the project using it, and that's where browserslist comes in.

Browserslist uses a simple syntax called "queries" to define the browser environment. You can easily specify the browsers and versions to support. You can explicitly target specific browsers and versions, or define them relatively, like "the last 2 versions." You can even select browsers based on usage statistics, such as targeting only browsers with more than 5% market share globally. This statistical information isn't fetched from an API server; it uses static data from caniuse-lite, a project that holds browser usage statistics and version information. That's why you often update the caniuse-lite data when using browserslist. Since the information browserslist provides is typically needed only once during the build process, this approach seems sufficient.

Queries

Browserslist uses a query syntax to define browsers. The queries are quite intuitive and easy to understand.

You can explicitly state that you want to support Internet Explorer (IE) version 10:

ie 10

You can also specify a version range:

ie 6-9

This means supporting IE versions 6 through 9. But seriously, let's ditch IE 6 through 10. Please be kind to web developers.

Queries can use not to create negative conditions:

not ie 6-10

This query means you absolutely will not support IE 6 through 10. Nice, right? I used to think that deeply understanding browser quirks was my bread and butter, but looking back, I think I would have been happier developing other skills instead of dealing with that stuff. Yeah, TMI.

For IE-related settings, a query like this is generally good:

not ie <= 10

This indicates that versions up to and including 10 are not supported.

One of the coolest features of browserslist is selecting browsers based on usage statistics:

 > 2%

This means supporting only browsers with a global market share of over 2%. You can also specify a country code to target a specific country or region like Asia:

 > 2% in KR
 > 2% in alt-AS

The first selects browsers with over 2% market share in South Korea, and the second targets over 2% share across the entire Asian region.

Another commonly used query is:

last 2 versions

This query selects the last two versions of each browser. It mostly refers to major versions. In Korea, developers often support the latest versions of modern browsers while selectively supporting specific IE versions. This query, combined with an IE support range query, will likely cover most cases. You could define things more granularly by including browser names, but projects needing that level of detail are probably rare.

last 2 Chrome versions
last 2 Firefox versions

And perhaps the biggest headache is browsers that are no longer supported. You can easily exclude these:

not dead

dead refers to browsers that have been officially discontinued by their vendor (e.g., IE 10). So, not dead means you only support browsers that are still maintained. Be careful when using this in Korea, as sometimes you might need to support discontinued browsers, so using this blindly could cause big problems.

You can also combine queries:

 > 1%, last 1 versions
 > 1% and last 1 versions

You can use or (represented by a comma) and and conditions. > 1%, last 1 versions selects browsers that either have more than 1% market share OR are the latest version. > 1% and last 1 versions selects only browsers that meet both conditions: having more than 1% market share AND being the latest version.

How to Define Queries

You can define queries in two ways:

1. Inside a .browserslistrc file
2. Using the browserslist key in your package.json file

Using a .browserslistrc file is the simplest method.

 > 1%
last 2 versions
not ie <= 10

Create a .browserslistrc file in your project root and enter the content above. For those in a hurry, you can probably just copy and paste the content above and adjust the IE part according to your project's needs, and it should work in most cases. Queries separated by lines act as or conditions, though not seems to behave like an and condition within the logic.

Using the package.json file is the method recommended on the official site. Define an array under the browserslist key in your package.json:

"browserslist": [
  "> 1%",
  "last 2 versions",
  "not ie <= 10"
]

Debugging Queries

You can immediately check if your entered queries are working correctly. From the directory containing your configuration file (it uses defaults if no file is found), run the following command in your terminal:

npx browserslist

The output will be a list of browsers corresponding to your query. If a browser you need to support isn't listed, you'll need to adjust your query.

and_chr 86
and_ff 82
and_qq 10.4
and_uc 12.12
android 81
baidu 7.12
bb 10
bb 7
chrome 86
chrome 85
edge 86
edge 85
firefox 82
firefox 81
ie 11
ie_mob 11
ie_mob 10
ios_saf 14
ios_saf 13.4-13.7
ios_saf 12.2-12.4
kaios 2.5
op_mini all
op_mob 59
op_mob 12.1
opera 72
opera 71
safari 14
safari 13.1
samsung 12.0
samsung 11.1-11.2

This is the result for the query entered earlier, as of November 29, 2020. Since it uses browser usage statistics, the results can change over time, right?

Other Useful Features

Using browserslist-ga, you can select browsers based on your website's Google Analytics data. Since this reflects the actual browsers your users have, it couldn't be more accurate. However, this only becomes meaningful once you have accumulated a sufficient amount of user data. For a blog like mine with few users... well.

You can have different configurations based on deployment or development environments. Similarly, you can define various query sets using intermediate keys. Refer to the official repository's documentation for details.

There's also a feature to extend definitions from other .browserslistrc files. You can define a base browser support query, share it, and extend it to create slightly different derived configurations. This helps eliminate duplication, right? Honestly, unless you have very complex queries, I didn't think it was particularly useful, but modules or frameworks using browserslist might require complex queries depending on their features. This is also well-documented in the repository.

Finally

There isn't much else to summarize specifically for this topic. But it feels empty not to add a closing... Anyway, browserslist itself doesn't have special functionality; it's a tool for tools, designed to make defining supported browsers easy to read and convenient. It plays a crucial supporting role.

It seems likely that it will be used for quite a long time in Node-based frontend development environments.