Browserslist Visualized

Have you seen the Browserslist concept? You make a .browserslistrc file at the root of a project, or a browserslist key in a package.json file, which indicates what browsers you want to support. Then any other code processing tool on that project and refer to it to make decisions about how to process that code.

It’s a nice idea because it encourages standardization. Rather than individual projects making up their own format for indicating browser support, they can share. There are two major projects that this is relevant for: Autoprefixer and Babel. Both of them are very specifically about processing code to support older versions of browsers, so it’s pretty damn great that they agree at how to configure thaBut t.

You use strings to explain what you want:

last 2 versions

That will support the last 2 versions of every browser. That’s pretty nice, as it means as browsers evolve and support more things, you process your code less. Less unneeded prefixes, less processing into older (and probably slower) syntaxes.

It can also use global browser market share and various other keywords. The default is:

> 0.5%, last 2 versions, Firefox ESR, not dead
Code language: CSS (css)

That means it will support any browser that has over half a percent of global market share, the last two versions of all major browsers, the latest version of Firefox’s Extended Support Release, but no browsers without security updates.

Maybe you like the general concept of scoping to versions, but have a specific browser you need to support. Here’s that in the alternate format without commas but line breaks instead:

last 3 version ie 11 safari 15

Which would look like this in the array format in a package.json file:

{ browserslist: [ "last 3 version", "ie 11", "safari 15" ] }
Code language: JSON / JSON with Comments (json)

A few notes:

  • I always trip up on the usage of “s”. It’s browserslist, not browserlist, the later feeling more natural to me.
  • You can interchange “version” and “versions”. It feels awkward to me to say “last 3 version” like you often see, but it’ll take the “s” just fine.
  • If you’re writing a code processor that you expect to behave deterministically, you’ll need to use unchanging targets. Using versions or market share will change over time and break your tests.

But what I really wanted to point out was this nice project I ran across recently: browserslist.dev — which shows you visually what browsers you’ll actually be supporting when you build your config.

Screenshot of https://browserslist.dev/?q=bGFzdCAyIHZlcnNpb25z

I like last 3 versions, not dead myself, but that’s not terribly far off from defaults so you might stick with that. I was just working on a thing where we were using defaults and supports es6-module, but turns out we could drop the and supports es6-module because we’re at a point where that literally does nothing to the supported browser list anymore.

While I was poking around at this I happened to be on a call with Eric Meyer and he pointed out another very similar site: browsersl.ist. Both sites allow you to share configurations and visually show you which browsers are being targetted. But this one is maybe a bit better as it has all the information on what configuraiton options are possible.

Screenshot of https://browsersl.ist/#q=%3E+0.2%25%2C+not+dead%2C+Safari+13%2C+last+2+versions

But Eric noticed that the data on this one is a bit more up to date. It had Chrome 109 data in there, for example, where the data on browserlist.dev only had Chrome 107 data.


CodePen

I work on CodePen! I'd highly suggest you have a PRO account on CodePen, as it buys you private Pens, media uploads, realtime collaboration, and more.

Get CodePen Pro

One response to “Browserslist Visualized”

  1. Ben says:

    Boggles me that we can’t just write “not IE” and must do “not IE > 0” or “not IE < 12”

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top ⬆️