New data is replacing old data

[lyml]

I was recently debugging why a polyfill of Object.Entries was being bundled even though our browserslist targets is fairly modern.

In doing so I noticed that and_chr 93 was added to our browserslist configuration. That was expected but surely and_chr 93 should support Object.Entries however when look at the caniuse data it seems to be replacing the history of support with whatever version is the latest.

https://github.com/Fyrd/caniuse/blob/main/features-json/object-entries.json

This contains only a single entry for android chrome:

"and_chr":{
  "94":"y"
},

And sure enough, this is visible on the caniuse website as if there was only a single version of chrome for android. This leads to our build tools determining that and_chr 93 does not have support for Object.Entries. Looking through the blame history this seems to have been ongoing for a long time, with each update of the containing only a single row for and_chr.

The general problem does not seem to be limited to Object.Entries and and_chr.

[Schweinepriester]

Related: #3518 and #2926

There is an old reply from @Fyrd: #3518 (comment)

But maybe it's time now - feel free to leave open to have him respond.

[Fyrd]

@lyml I'm curious as to why your browserslist configuration is set up to specify particular browser versions? Chrome releases updates now on a 4-week cadence so I believe most configurations use things like "last 2 versions" or set a usage threshold to avoid having to regularly update manually.

[lyml]

@Fyrd

I was being a bit sloppy in my formulation there, I meant that the result of our configuration included and_chr 93 and this change was expected since adding support for mobile browsers to our build tools.

Since the data replacement isn't a mistake I have since then read the inner workings of how babel solves this problem and if I have understood it correctly it seems that they simply assume that the mobile browsers match their desktop variants.

This is of course less than ideal but we can use this workaround as well.

I have read the earlier answers and understand it is an issue about having access to older versions of mobile browsers. I understand if you do not wish to change the methodology, but would it be possible to append the table with whatever new information about a mobile browser you manage to ascertain instead of removing the old data?

For specifically Object.entries that would mean that the and_chr would look like this:

"and_chr": {
  "71": "y",
  "73": "y",
  "74": "y",
  "75": "y",
  "76": "y",
  "78": "y",
  "79": "y",
  "80": "y",
  "71": "y",
  "84": "y",
  "85": "y",
  "86": "y",
  "87": "y",
  "88": "y",
  "89": "y",
  "90": "y",
  "91": "y",
  "92": "y",
  "93": "y",
  "94": "y"
}

Which we could then use to see that version and_chr 93 does indeed support the specific feature we are looking at.

[Fyrd]

Yeah, I have been thinking of changing it to just the last 10 or so versions instead of just one. Glad to hear you have a workaround for now.