Update browserslist browsers

+++ b/core/package.json
@@ -71,12 +71,18 @@
-                  "ie >= 9",
-                  "edge >= 13",
-                  "firefox >= 5",
-                  "opera >= 12",
-                  "safari >= 5",
-                  "chrome >= 56"
+                  "last 2 Chrome major versions",
+                  "last 2 Firefox major versions",
+                  "last 2 Safari major versions",
+                  "last 2 Edge major versions",
+                  "last 2 Opera versions",
+                  "last 2 iOS major versions",
+                  "last 1 Explorer major version",
+                  "last 1 ChromeAndroid version",
+                  "last 1 UCAndroid version",
+                  "last 1 Samsung version",
+                  "last 1 OperaMini version",
+                  "Firefox ESR"

This matches https://www.drupal.org/node/3079238 exactly.

With two exceptions:

1. Chrome for iOS is absent from this list.
2. Why Firefox ESR and not last 1 Firefox ESR version?

#4.1 It doesn't seem like there is a query for chrome ios, I compared against https://github.com/browserslist/browserslist#browsers

#4.2 Firefox ESR currently returns versions 68 and 60, last 1 Firefox ESR version is not a valid query, it's not in https://github.com/browserslist/browserslist#full-list

This can also be verified by:
editing package.json and running yarn build:js,
by running npx browserslist 'last 1 Firefox ESR version' in the console from the core directory compared to npx browserslist 'Firefox ESR'
or at https://browserl.ist/?q=last+1+Firefox+ESR+version compared to https://browserl.ist/?q=Firefox+ESR

I also saw no changes in production code after running yarn build:js which was surprising, however if I removed "last 1 Explorer version" there were big changes so it is clearly working!

To get a sense of which browsers are in this list, I copied the entire "browsers" in package.json to a "browserslist" key at the top level, and ran npx browerslist from the core directory. This is the output I got:

This is a huge improvement, and besides trimming down the list now specifically supports opera mini which it didn't seem to before.

Thanks, @zrpnr!

It's super weird that Firefox ESR is this special snowflake :O Apparently ESR is short for Extended Support Release. By definition it targets all currently supported "extended support" Firefox release (https://github.com/browserslist/browserslist#full-list says "the latest [Firefox ESR] version"). But https://browserl.ist/?q=Firefox+ESR currently returns both Firefox 60 and 68, and so does npx browserslist 'Firefox ESR'. Meaning: two versions, not one. Okay! 👍 But … https://www.drupal.org/node/3079238 and https://www.drupal.org/docs/8/system-requirements/browser-requirements say we only support the latest version of it. This is confusing. It looks like this is simply a limitation of the browserslist infrastructure.

I am not the first to notice this: https://github.com/browserslist/browserslist/issues/148.

It does mean that Drupal core is not quite complying with its own official policy at https://www.drupal.org/docs/8/system-requirements/browser-requirements — it means it will support slightly more. But without extra effort being required for Drupal core maintainers.

That's probably acceptable: we don't officially support it, but due to a tooling limitation there is soft support for the oldest Firefox ESR version that Mozilla still supports.

Yep, I should've mentioned that 🤦‍♂️👍

That's probably acceptable: we don't officially support it, but due to a tooling limitation there is soft support for the oldest Firefox ESR version that Mozilla still supports.

Let's add FF 68? One manual update per year, I think that's fine.

Technically, this is required to add browserslist & caniuse-lite to package.json and run `yarn upgrade browserslist caniuse-lite` on each update period (, the time to refresh Drupal support list) to ensure this is running on the latest DB.

Let's add FF 68?

That's already included in Firefox ESR:

$ npx browserslist 'Firefox ESR'
npx: installed 5 in 1.71s
firefox 68
firefox 60

😊

Hrm, but @droplet brings up an interesting implied problem: how do we ensure that every single core developer is using the exact same list of browsers?

Our yarn.lock specifies:

browserslist@^4.6.3:
  …

And if you go and look at the code for version 4.6.3, you see that https://github.com/browserslist/browserslist/blob/4.6.3/index.js#L858 contains:

      return ['firefox 60']

but running npx browserslist 'Firefox ESR' returns both 60 and 68 like I showed in #10, and @zrpnr showed in #5 before me.

Contrast that with version 4.6.6, where https://github.com/browserslist/browserslist/blob/4.6.6/index.js#L860 contains:

      return ['firefox 68', 'firefox 60']

How is this happening? Well, my yarn.lock actually contains:

browserslist@^4.6.3:
  version "4.6.6"
  …

So everyone who does yarn install locally is already guaranteed to get the same results.

👍

Neat!

Will this have any disruptive impacts? E.g., will it cause new versions of dependencies to be packaged, or other disruptions? I think this might be answered by #2:

Here's an updated browserslist. I ran yarn run build:js to ensure this didn't result in any changes in the production code.

...but I just want to confirm that that will also be true for sites, modules, etc.

We should add a CR for this, or maybe just add it to the CR for the browser policy. It may or may not be worth adding a release note. (I don't actually know what this package does -- supports JS transpilation I'm guessing?) Could use feedback on whether there's a reason to mention it.

Also, if this does affect JS transpilation, have we taken into account yet how we will handle this for patch releases? For our allowed changes policy, we wouldn't want to accidentally break transpiled in a patch release. (There could be a scenario where a browser releases a new version, and someone commits an otherwise non-disruptive JS bugfix that results in a new transpilation, and then the patch release breaks someone's site for their users and they file cranky bug reports.)

#10
drop Firefox ESR and add FF 68 instead

#11
You're running outside the `core` dir I bet.
broswerslist also showing the warning:
https://github.com/browserslist/browserslist/blob/0ae7155a6c7d8f58eaeb3e...

But simply to run `yarn upgrade` without package.json dependencies won't work.

#13
that's one of the reasons why I raised the question: https://www.drupal.org/project/drupal/issues/2390621#comment-13249420

- When to drop the older supports? At release date or beginning of a new branch?

This is not predictable like "Firefox ESR" release cycles.

If this is committed today, iOS 11 still on the list. But I think everyone here is expected to drop it. A week later, the data will catch up.

There could be a scenario where a browser releases a new version, and someone commits an otherwise non-disruptive JS bugfix that results in a new transpilation

This is a common occurrence if you're not specifically pinning your browser versions, which is more suitable for projects that have a build step. If you're worried about it I would go back to being specific about the oldest browser version to transpile to, though I think it's extremely unlikely it would actually cause a breakage given how widely the transpiler is used and the time it takes for a Drupal release to become available.

#3060153: Use PostCSS in core, initially only for Claro just landed, this now needs to be rebased.

The "browsers" key is no longer nested under "babel" but now is in the top level as "browserslist".
Re-rolled the patch moving the list of browsers to the current location in package.json

No change to the minified js when running yarn build:js and the list of browsers can now be verified by running npx browserslist in the core directory.

That sounds right! Thanks for the reroll 🙏

We should add a CR for this, or maybe just add it to the CR for the browser policy. It may or may not be worth adding a release note. (I don't actually know what this package does -- supports JS transpilation I'm guessing?)

https://www.drupal.org/node/3079238 already sort of covered it, but now it does explicitly. Yes, transpilation is what it does.

Now that there are no tags indicating further work, let's look at the comments since RTBC that still need addressing.

• @xjm's interpretation in #12 wrt impact is correct. No disruptive impact. No dependency changes.
• #13 is a question for #2390621: [policy, no patch] Update Drupal's browser support policy, not for this issue. AFAIK we only change the list of supported browsers in minor versions, never in patch releases.
• @droplet's concerns in #14 were addressed by @justafish in #15.

The supported browsers list according to this change: