The thing is that there is the Promise "class", which is provided by the environment, but there is a interface called PromiseLike, which is defined as having a method called then that takes one or two functions. Now, JS doesn't have nominal typing for interfaces, so you have to do "random property checks".

Typescript partially solves that by declaring types, but if you have a any variable, you still need to do some probing to be able to safely convert it to a PromiseLike, because TypeScript goes to great lengths to not actually produce physical code on its output, attempting to be just a type checker.

Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided, but alas, this is not the case.

shouldn't it then be called is-promise-like? Also, if you're being loose about it anyways, can't you simply just go for `if (obj && typeof obj.then == 'function')` and call it a day? I'd say that's short enough to include your own version and not rely on a package for.

I think that module over complicates it as it is, and most people don't need that level of complication in their code.

> Perhaps if TS or an extension allowed "materializing" TS, that is `value instanceof SomeInterface` generated code to check for the existence of appropriate interface members, this could be avoided

It's not perfect and a bit of a bolt-on, but io.ts works reasonably well in this area:

https://github.com/gcanti/io-ts

In theory `x instanceof Promise` would work, but the reason for this package is that there are many non-standard Promise implementations in the JS world.

It wouldn't work even if everything were native – see my reply above.

That applies for browsers, yes (though I'd argue is a rare edge-case), but create-react-app is a Node.js application.

create-react-app isn't even using is-promise directly. It's several hops in the dependency graph away.

Promises were not always part of the standard and for many years were implemented in user space, by many different implementations. Using duck typing like this was the only way to allow packages to interact with each other, as requiring an entire stack to say only use Bluebird promises is not realistic at all.

I'm totally with you on this. It's dumb that this is a problem but it is actually a problem.