Skip to main content
Dublin Library

The Publishing Project

Adding browserslist support to your project

 

A lot of the tools in my projects like Autoprefixer, Babel's preset-env and preset-modules use browserslist (yes that's the name, no typo) to decide if adding prefixes or transpiling is required.

The hardest thing for me to decide is what versions to support and whether they will be the same for all projects or all tools.

For example, I'm all for supporting ES2017 and earlier in my projects. ES 2017 support means that we're supporting all the features I would like to use in my projects without having to be afraid of substantial differences in support or broken implementations (broken implementations are always possible but less likely).

The table below shows the earliest browser that supports module scripts and the full set of ECMAScript 2017 features.

Feature Supported Chrome Edge Firefox Safari
<script type="module"> 61+ 16+ 60+ 10.1+
All ES2017 features (minus atomics+shared memory) 58+ 16+ 53+ 10.1+

This could be easily included in a .browserslistrc configuration file or as part of a package.json file. A .browserslistrc file for the browser versions that support the <script type="module"> looks like this:

Chrome > 61
Edge > 16
Firefox > 60
Safari > 10.1

and the equivalent JSON that can be inserted in your package.json implementation, looks like this:

  "browserslist": [
    "Chrome > 61",
    "Edge > 16",
    "Firefox > 60",
    "Safari > 10.1"
  ]

We can use the browserslist configuration as the first step when we use the module/nomodule pattern.

Using these settings as the compilation target we'll get a module that will work in all our target browsers and be ignored by browsers that don't support modules.

A second compilation target can address the browsers that don't support modules and that will likely not support the language features we want to use.

Yes, I am aware of the small gap between full ES2017 support and script type="module" support. I'm OK with it; evergreen browsers will continue to update to where it becomes irrelevant.

Publish, ship, and install modern JavaScript for faster applications provides examples of how we might do this using WebPack and other tools.

Edit on Github