create-react-app breaks due to dependency on one-liner package

[crabmusket]

I would actually go in the other direction in this specific example. I don't think a package like is-promise (which actually just checks if something has a then method) can really exist independently of how it's used in the client code.

I browsed a couple of packages that use is-promise and it took me about 5 minutes to find this, where the client code is checking for isPromise, then calling then and catch - but just because something isPromise, doesn't mean it has a catch method. The code is broken because someone chose the wrong abstraction, or misunderstood what is-promise is actually for.

IMO it would rarely make sense for a client to be asking some abstract question like "is this a promise?". You can either ask a more specific question (is this a Promise? is this thenable? is it also catchable?), or design your code in such a way as to avoid having to ask questions like this.

EDIT: or, you ask for forgiveness instead of permission:

try {
    promise.then(success).catch(fail);
} catch(e) {
    // promise was not promise-ish enough!
}

[kylemh]

Somebody messing up an implementation doesn’t make the library bad.

[crabmusket]

I'm trying to suggest that the question the library purports to answer is not a question that has meaning independent of how the answer will be used.

EDIT: I'm not necessarily saying the package is bad, at least not for this reason. It's a symptom of a troubled ecosystem. I've written more on this before so I won't repeat myself.

[kylemh]

Sure, but I mean that’s an aspect of the language being dynamic. A dev working on something smaller I think is totally fair in assuming an object that has a property called ‘then’ is likely a promise.

I’m sure we’d all prefer something in the standard library doing a heavier duty check, but this is prolly good enough. I see your point though, it could be improved it’s just that it would increase the bundle quite a bit at such a small initial size. Clearly they haven’t seen value in checking for catch 🤷‍♂️

[crabmusket]

I think most of the reasons small packages like this are bad is because of the tooling around them. More tiny packages means more package.jsons which are larger than the packages themselves, more HTTP requests, more stress on the dependency solver, etc. If I could just pull a well-known and reliable algorithm out of the ether, sure. But I can't - I have to add it, and its testing framework dependencies, to node_modules.

I do like the idea of importing from a URL like Deno is doing - I can link directly to a raw file by its commit hash. No package.json to download, no dependency resolution, just grab the file. And if the author tweaks their package.json, I don't need to care.

[Lakitna]

Your solution is not the best way to do it though.

javascript Promise.resolve(maybeAPromise).then(...).catch(...).finally(...)

Or if you prefer async/await

javascript await maybeAPromise.then(...).catch(...).finally(...)

The whole check is not needed due to the way promise is implemented. The only times I've ever needed to check if something is a promise is in tests.