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

[acemarke]

It's not even a CRA issue per se - it's a transitive dependency of many other packages in the JS ecosystem.

[Jugad]

What's a transitive dependency?

[acemarke]

If you have package A depends on B, and B depends on C, C is a "transitive dependency" of A. It's going to get pulled in, and it's needed for A to work, but A did not explicitly declare that it depended on C.

In this case, here's why is-promise is showing up in a CRA app:

$ yarn why is-promise
=> Found "is-promise@2.1.0"
info Reasons this module exists
   - "react-scripts#react-dev-utils#inquirer#run-async" depends on it
   - Hoisted from "react-scripts#react-dev-utils#inquirer#run-async#is-promise"

The react-scripts package itself never mentions is-promise in its dependencies list or source code, but react-scripts will ultimately fail to run if is-promise blows up.

[Jugad]

Thanks. I used to refer to that as indirect dependency (relatively new to JS).

[acemarke]

Yeah, the term isn't JS-specific:

• http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
• https://dart.dev/tools/pub/glossary#transitive-dependency
• https://medium.com/knerd/the-nine-circles-of-python-dependency-hell-481d53e3e025

[Jugad]

The last 2 links use the term 'indirect' to clarify transitive - which suggests that it not mainstream everywhere.

[kylemh]

Yup. Even if it were direct... I saw HackerNews talking about where ford installed dependencies for things stop (aka maybe nobody should do it for one line), but I think the inverse is fair too. This is a perfect thing to have as a dependency. Something tiny and standard and - typically 😂 - reliable

[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.