Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Ensure that the return value of apiFetch is always a valid Promise object in Firefox #10214
If I'm known for one thing, it's for my nagging relentlessness in not allowing "I don't know" to pass
It is an issue related to polyfills. Specifically, the native promise is overridden in Firefox due to lack of support of a
So, I think this is more an issue of how we detect things as promises (in our promise middleware) rather than the return value of fetch, which is in-fact a promise.
That was my original way of fixing the issue, but we do test promises in several places. Should we update them all?
What should we consider a promise: an object with a
I did try to search for the issue elsewhere but failed. You're more skilled then me :)
I think this is safest in reality where promises are often polyfilled, even if it is not quite as semantic as testing it against the
Ultimately, It's a small difference that I don't care too much one way or the other. My bigger concern was having the understanding of what was causing the issue, so we could at least be well-informed to be able to evaluate the best solution.
Thanks for digging into this @aduth. If the "intuitive" way to check for Promises is problematic, seems like we should be relying on a library (like other projects do) to detect Promises. @aduth mentioned: https://www.npmjs.com/package/is-promise... I think it makes more sense to update our checks to use something like that
is-promise library. I worry otherwise we'll just run into edge cases like this again.
It might be nice to enforce a rule about it if possible, maybe alert if you are checking for
instanceof Promise or whatever, but that can happen later; I'm not sure how we test across the repo.