You can await literally anything in JS.

await 100
await null
await someAsyncFunction()
await someNonAsyncFunction()
await (new Promise((resolve) => resolve()))

You can even create a getter that returns a promise and await it.

const foo = {
  get usersDogsName() {
    return new Promise((resolve) => {
      fetch('/users/12345/dogsName')
        .then(response => response.json())
        .then(resolve)
    })
  }
}

await foo.usersDogsName

… Or await a getter that is not asynchronous. (I guess it is worth adding for clarity.)

const bar = {
  get age() {
    return user.age
  }
}

await bar.age

I’m refactoring an old library that both accepted a callback and would return a promise. Although that was pretty convenient, it made for some pretty ugly gymnastics in each class method in order to check for the callback and shift around optional parameters. My theory is to only write async methods for the refactored version, but to supply a Proxy that could be used to wrap a class and convert all async methods to support a callback as well. For backwards compatibility simply wrap your instance in the Proxy.

This seems like it provides the missing piece I need.

That shouldn’t be confused with whether it is grammatically possible to ‘equalize’ all callbacks by wrapping them in a Promise so that they are all asynchronous.

const AsyncFunction = (async () => {}).constructor;
const GeneratorFunction = (function* () {}).constructor;

const isAsyncFunction = value => value instanceof AsyncFunction;
const isGeneratorFunction = value => value instanceof GeneratorFunction;

isAsyncFunction(async () => {}); // true
isGeneratorFunction(function* () {}); // true

And also a shorter version with pretty much the same logic you have:

const isAsync = myFunction[Symbol.toStringTag] === "AsyncFunction";

Cheers!

I’ve had to do this in the past for using decorators, as the decorator had a check that could be used on any function, but the descriptor value had to be set to specific types of functions (generator, async, normal, etc.) or else it would break the decorated method.

Promise.resolve( unknownFunction(/* args needed */) ).then( value => {
   /* whatever you need to do with the value */
} );

and that only in the case of consuming transpiled code but your own code can’t use await. In the case of full native async/await environment, await value works even if the value is not a Promise, so there’s no need to know is function is async or not.

async function getPerson(id) { .. }

function getRecord(id) {
   return getPerson(id)
      .then(function(person){ return { data: person }; });
}

In other words, both functions return a promise, and thus you should interact with both of them in the same way, receiving that promise and doing something appropriate with it, regardless of the “kind” of function that was called. The type of the return value is the important characteristic.

Ostensibly, the only reason you need to check if a function is async or not is as a sort of identity check to figure out if you should expect a promise returned or not. But that is a brittle and unreliable sort of assumption, since getRecord(..) above would fail the check but still returns a promise.

Try to write code so that it’s obvious and reliable, regardless of function kind, whether a promise or immediate value will be returned.