This function is most likely an artifact of before promises got standardized. One way promises took off and became so ubiquitous is different implementations could interop seamlessly. And the reason for that is a promise was defined as 'an object or function having a then method which returns a promise when called'.

Doesn't excuse the JS ecosystem and JS as a whole, which truly is a mess. But there's a history behind these things.

I think the point of the comment is: you should not be testing for this at all.

If your API works with promises, call .then() on what is handed to you. That's it. Don't make up emergent, untestable behavior on the spot.

You need to do this test if you are creating a promise implementation. That was my point, there is a reason code like this exists.

Why would an implementation need to test for it?

ISTM that a framework may need to test for promiseness if it calls promises and functions differently, but it can and should be done as a utility in the framework, not as a separate package.

I agree with that. I have no idea why it’s in a separate package. But I can say that about many packages :).

It’s possible to just treat everything as a promise by wrapping results in Promise.resolve() but that can have performance implications that some franeworks might want to avoid by only going down the promise route when they have to.

For promise implementations, If the callback to then() returns a promise, the promise implementation detects that and resolves that promise behind the scenes: http://www.mattgreer.org/articles/promises-in-wicked-detail/...