polyfillpolyfill
no-version scenario changed, maybe?
hi, thanks for maintaining a great projects!
we have been pulling in https://cdn.polyfill.io/v3/polyfill.min.js for years
very recently (maybe the morning of Feb 24), we started to have very confusing problems in our app
after some investigation it was discovered that replacing that dependency with https://polyfill.io/v3/polyfill.min.js?version=3.111.0 fixes it
viewing those two files in a modern web browser, the second one shows no code, the first one shows a lot. so what i think happened is the behavior of the first one changed recently to no longer smartly adapt to the browser version. so maybe there's a new bug when the version= param is missing. but, i'm not 100% sure what behavior was before.
(cdn. and non-cdn. behavior is the same in both cases currently)
let me know if you want any more info!
My guess is that this is a caching issue, similar to https://github.com/polyfillpolyfill/polyfill-service/issues/2801. I see a useragent_normaliser: ios_saf/11.0.0 response header, which does not match my user agent. If I add just a ? at the end of polyfill.js, the problem seems to be resolved.
We also had the exact same issue starting today, on Chrome we get a response header of Useragent_normaliser: ie/11.0.0 if we do not stub the minor version in the query parameters. The polyfill injected unneccessary methods into our production code and we crashed at initialization.
We experienced the exact same issue on February 24th. We support older devices and Object.fromEntries was not polyfilled anymore. This is unexpected behaviour, as our src looks like this: https://polyfill.io/v3/polyfill.min.js?features=default%2CIntl%2Ces2015%2Ces2016%2Ces2017%2Ces2018%2Ces2019%2Ces2020%2Ces2021%2Ces2022 and the documentation lists Object.fromEntries to be polyfilled in es2019:
Updating our src to
https://polyfill.io/v3/polyfill.min.js?version=3.111.0&features=default%2CIntl%2Ces2015%2Ces2016%2Ces2017%2Ces2018%2Ces2019%2Ces2020%2Ces2021%2Ces2022 fixes the issue (adding the version).
Hi, I don't know the details but this issue seems to be related to #2834. The timing (on Feb 24) matches this domain transfer date.
Since today, we (sporadically) experience the same issue again, even when including the fixed version number in the URL. We also saw other related issues in the repo. What is going on?
please provide full url for version that is not correct, we will clear it from cdn cache
