-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A better way to detect native Promise? #56
Comments
If I recall correctly, I did it this way because there was a common |
Is there a case where the current approach is causing issues? |
I could see an argument for combining the 2 methods in case the Pollyfill |
Ah yes you are correct - if a function is bound it will be detected as native 😞 ... because obviously it is native. It will however not have the name I must admit that the reason why I proposed the change is very selfish. I'm using 99% of the code from index.js internally in the opbeat module so neither The main reason why I'm using my own implementation instead of adding this module as a dependency is to optimise the |
Right now the presence of native Promise is detected based on how the code is currently instrumented and how it behaves when used:
async-listener/index.js
Lines 260 to 274 in 0c2e2ec
I was thinking that there might be a better way of detecting if the current Promise implementation is native or not - simply by checking if
global.Promise
is a native function or not.The simplified approach to check this would rely on the result of
String(global.Promise)
which produces the following string:The presence of
{ [native code] }
gives it away.But as the blog post Detect if a Function is Native Code with JavaScript and the is-native module shows, there are some edge cases that should be checked.
So my question is, could we simply not require
is-native
or something similar and replace line 257-274 with the following snippet?The text was updated successfully, but these errors were encountered: