isAsyncFunction fails when checking an async function transpiled via Babel to ES5.

[tranhl]

If a fix is not possible, then I believe that this edge case should be added to the docs.

To Reproduce

1. Write an async function declared with the async keyword.
2. Call isAsyncFunction on it.
3. Transpile the async function with Babel to ES5.
4. Call isAsyncFunction again, and note

Expected behavior
isAsyncFunction works on async functions after transpilation.

[char0n]

Yes this can cause dangerous bugs in your code. But we've dealt with this problem before and the current strategy is not to handle this because I don't think this is a problem we can solve. We build our predicate functions on behavior of native EcmaScript features specified in EcmaScript specification. We cannot compensate for cases of transpilers like babel transpiling one form of JavaScript code into another form...and even the form of transpiled code changes all the time.

The current strategy that I'm personally using in my project where I need to transpile, is to use common lowest denominator. So if I know I'm targeting envs where Async functions are not supported and they are transpiled into standard function is use isFunction instead.

If you have any suggestion I'm open to it

[tranhl]

After doing some research myself, I'm in agreement that supporting Babel-fied code is practically impossible. Writing code in a way that does not requre isAsyncFunction seems to be the best practice.

How about adding a warning to the documentation that states isAsyncFunction's behavior is unreliable in transpiled environments?

[char0n]

Agree, it's almost impossible. This problem easily concerns 40% of our functions, depending what env we want to target with transpilation. You can target even node 0.10.0 with transpilation.

How about adding a warning to the documentation that states isAsyncFunction's behavior is unreliable in transpiled environments?

Good idea: #1394

Thank you!