sindresorhus
Errors in Safari < 17.4 due to using AbortSignal.any
Hey guys. I've tried 1.8.0 version of the lib but was forced to downgrade it to 1.7.5 because of error reports about using AbortSignal.any that doesn't work in safari older than 17.4. This version of safari was released in march of 2024 so I believe there is sense to support it too
Here is usage of AbortSignal.any https://github.com/sindresorhus/ky/blob/93c02ac7817df1138e97e8971fe5165e30d68097/source/core/Ky.ts#L173
Ky targets the latest browser versions, but we can add a note about using a any polyfill for older Safari versions.
Since Browser API cant be automatically polifilled and it requires manual action having a note would help a lot
Would it be possible to reserve breaking changes like this for major version updates in the future? This bug is preventing some users from accessing my website.
I sympathize but I'm afraid that is not how semver works. Bug fixes and security updates can change behavior that technically "breaks" user code, but they are not considered major revisions.
If a change forces us to modify existing tests, that's a good indication that it may deserve a major version bump, but even then, if the behavior is undocumented, it's really at our discretion whether we think it makes sense to do so.
In this case:
- Our documentation clearly states support for "latest browsers".
- Safari 17.4 is more than a year old and isn't even within the 18.x range.
- We have not changed our API contract. If we did, that would be a major version bump.
- The implementation details of how signals are combined is undocumented.
- The change was made as a bug fix for a memory leak.
Also, perhaps most importantly, our current testing infrastructure doesn't give us the ability to run regression tests against old browsers. We could potentially integrate BrowserStack to do something like that. I am open to it if someone sends a PR. That would at least make it easier to be aware of the situation, regardless of whether we decide to officially change our support policy.
Unfortunately, AbortSignal.any is not easily polyfill-able b/c it requires WeakRef. See https://github.com/zloirock/core-js/issues/445#issuecomment-1817361034
In light of that perhaps it's worth not using AbortSignal.any until browser support is better? @sindresorhus
Safari has had WeakRef for even longer, since v14.1, which was released in April, 2021. This shouldn't be an issue for most people.
That said, if you need it, I would be happy to provide commercial support and discuss options for solving edge cases like this.
Also encountered this issue for visitors with older browsers that are not easy to update, mostly iOS devices.
Downgraded for now. But it's a bit sad that a minor bump caused this.
The support policy for almost all of your browser-based dependencies is going to be "latest and latest - 1". So if you haven't run into something like this with other libraries, you've just gotten lucky so far. It's a result of the fast pace of browser development along with most browsers using auto-update.
That said, I think it's perfectly valid to want more. It would be nice to at least not accidentally and unknowingly upgrade our minimum working browser version, regardless of what we officially support. To do that, we would really need the ability to pin to a specific browser version in our test suite, like we do for Node.js versions. Alternatively, we could use lint rules for the same purpose. A PR for that would be very welcome.
The support policy for almost all of your browser-based dependencies is going to be "latest and latest - 1". So if you haven't run into something like this with other libraries, you've just gotten lucky so far. It's a result of the fast pace of browser development along with most browsers using auto-update.
That said, I think it's perfectly valid to want more. It would be nice to at least not accidentally and unknowingly upgrade our minimum working browser version, regardless of what we officially support. To do that, we would really need the ability to pin to a specific browser version in our test suite, like we do for Node.js versions. Alternatively, we could use lint rules for the same purpose. A PR for that would be very welcome.
To be clear, I don't blame any contribution or this project for this issue. I think it's very reasonable to limit support on free and open source projects.
In our case the polyfills are handled by nextjs, but unfortunately they don't provide a polyfill for Abort signal.any so that's pretty unfortunate.
Good idea with the linting, I might look into it and create a PR.
Thanks for your time.
Took a look at https://github.com/amilajack/eslint-plugin-compat and it seems pretty fitting. Anyone knows a better alternative?
A fix for this has been merged.
Note that timeouts will not work in these environments without support for any().