[wp-trac] [WordPress Trac] #52331: Consider using more precise browser versions for `browserslist`

[WordPress Trac]

#52331: Consider using more precise browser versions for `browserslist`
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Build/Test Tools                     |     Version:  4.9
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch has-unit-      |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by kraftner):

 I happened to find this ticket on a tangential issue: Trying to rebuild
 the core block styles for a certain WordPress version in isolation. But
 the problem I faced boils down to exactly what this issue is about.

 **Me rebuilding core block styles**

 My approach basically was to look at the `package-lock.json` of a release
 to get the versions of the `@wordpress/block-library`, `@wordpress/base-
 styles`, `sass` and `@wordpress/postcss-plugins-preset` packages. I also
 copied the `browserslist` array from the `package.json`.

 But when I built I still didn't get the same files because of my
 `browserlist`/`caniuse-lite` data of course was more recent. I then tried
 to get that as well from the `package-lock.json` file but soon noticed
 that for some WordPress versions there are multiple different versions of
 the data spread as sub dependencies of various packages. Since npm
 apparently offers no way to force those sub-dependencies only manually
 messing with the `package-lock.json` remains.

 I tried that but still wasn't able to build a 100% match for some
 WordPress versions (5.6.2 being specifically nasty) before I gave up.

 So basically I came here to say two things:

 **De-duplicate data before release**

 It would be great if when building/releasing WordPress the data would be
 updated and brought in sync across all packages like @netweb
 [https://core.trac.wordpress.org/ticket/52331#comment:27 already proposed]
 and [https://github.com/browserslist/browserslist#browsers-data-updating
 the documentation for browserslist also recommends].

 If ''updating'' isn't wanted (which seems to be the intention of this
 ticket) a script similar to the
 [https://github.com/browserslist/browserslist/blob/main/update-db.js
 script mentioned above that does the updating] could be created that only
 de-duplicates `caniuse-lite` without updating. See my next point:

 **Locking might still not work**

 I suspect (although that is completely untested) that even if you lock
 down the browser versions and remove the `> 1%` rule there still might be
 changes since the caniuse data might still be changed in the meantime for
 the specified browser versions. Since caniuse data is
 [https://github.com/Fyrd/caniuse/blob/main/CONTRIBUTING.md a community
 effort] support data might still change for a browser version after a
 WordPress release even without our browser support definition changing.

 So I think the only way to lock down Autoprefixer to a specific behavior
 is to lock/force all uses of `caniuse-lite` to a specific version. I think
 this could maybe be done by running the aforementioned `npx
 browserslist at latest --update-db` to only get one instance of `caniuse-
 lite` installed at root level, then uninstall that and install the
 historic version everything should use.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52331#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform