Why use one line of code in the form of a separate library

[intech]

Why use one line of code in the form of a separate library by creating a dependency graph, increasing the build time of the project. What is this trend?

[intech]

P.S: magic for node.js in docs https://nodejs.org/api/util.html#util_util_types_ispromise_value

[szmarczak]

People may use different tools than Node.js

[intech]

People may use different tools than Node.js

You're right. I got here from a project error node.js = (

But, the question posed as the basis for the issue of optimizing the dependencies of such packages. This is a very serious question, we have thousands of dependencies. All this in the future turns into endless refactoring of libraries, programs for tracking broken dependencies, tracking vulnerable dependencies.

[szmarczak]

You're right. I got here from a project error node.js = (

Then open an issue there. is-promise is not the right place.

[joepie91]

This question is addressed here.

[simon-robertson]

Why use one line of code in the form of a separate library by creating a dependency graph, increasing the build time of the project. What is this trend?

The issue here is not the development and use of tiny libraries, both sides of that coin have pros and cons, the issue is the lack of testing before publishing. There really is no excuse for the latter, especially when a tiny library has so many dependents.

Unfortunately the JavaScript ecosystem's dependency tree is now so vast it is easily broken; as a lot of us have experienced over the last few days.

[joepie91]

Unfortunately the JavaScript ecosystem's dependency tree is now so vast it is easily broken; as a lot of us have experienced over the last few days.

Package count has zero relevance to likelihood of breakage. Packages are merely distribution units; the risk is contained in the complexity contained within those packages, which is overall smaller with a lot of small packages as compared to a few large ones (because larger packages will pull in complexity you don't need for your usecase).

In other words: a botched release could have happened just as easily with a large library, I'd even argue that it's more likely. It would be very nice if people didn't constantly take every tiny problem in the JS ecosystem as an excuse to superficially rail against single-responsibility packages. It's extremely tiring.

(Lack of testing is a problem, to be clear; but based on the postmortem for this incident, this was a freak incident that couldn't have reasonably been foreseen; because it only broke upon installation, not during code tests.)

[simon-robertson]

@joepie91 I agree with you. My last statement was about the ecosystem in general. I have no problem with tiny libraries, my issue here is the lack of testing of tiny libraries; and the number of dependents does matter in this case.

On the plus side, tiny libraries are easily fixed.

[joepie91]

@simon-robertson Ah, my apologies. I've already had a few encounters with the this-is-why-JS-is-evil mob over this incident, so I may be a little too quick on the trigger at the moment :)

I still do question whether this particular issue could have reasonably been foreseen and prevented. "Packaging errors" aren't exactly a common category of error in JS, so it doesn't necessarily make sense to write tests for that, especially if the impact of the failure is so small - because this failed early and loud, and so should have been caught by consumers of the library upon updating their dependencies, without breaking production systems.

[intech]

@joepie91 @simon-robertson I do not use such libraries in my projects and perceive them no more than snippets or patterns. Why am I doing this? I am responsible for my project and the quality of its work, which means I need more control over its code. I cover it with tests 100%. You are absolutely right that in large libraries this can happen exactly the same. But in this situation, large libraries broke down precisely because of the small one. The difference between a large and a small library is that you can not make a small one an additional dependency on a third-party developer, but shift its support and coverages tests to yourself. In a large library, I do the same with PR, helping to correct the errors found. Transferring it completely to my project is already expensive and long. We conclude that the small library as a result brought more loss of time and money for someone else's uncontrolled negligence, which can be avoided and risks reduced without using them as dependencies in large projects.

[joepie91]

But in this situation, large libraries broke down precisely because of the small one.

We conclude that the small library as a result brought more loss of time and money for someone else's uncontrolled negligence, which can be avoided and risks reduced without using them as dependencies in large projects.

What matters isn't a single incident, but a bigger trend, and the sorts of failures that you can expect from a particular model. Everything breaks sometimes; the important thing is to minimize the frequency and, more importantly, the impact over time.

Had the author of this library maintained a bigger library, they would have made the exact same packaging mistake and it would have broken in the exact same way, except now it would affect even more people because the library would be trying to address more issues for more people (and therefore be used more).

In other words: it being a small library just isn't a relevant factor here, at all.

I am responsible for my project and the quality of its work, which means I need more control over its code. I cover it with tests 100%.

While I agree with taking responsibility for your work (and I think more people should do this!), I disagree that that means you need to "control all the code" or "cover it with tests 100%".

Automated tests are spot checks; there is no such thing as "perfectly tested code", it's always going to be your best personal attempt at enumerating all the possible cases, and you will almost certainly miss some cases; just like everyone else would. It wouldn't have helped in this specific case either, because just importing the module would have produced the error; automated tests would not have improved on that.

Ensuring the quality of your work also doesn't mean that you need to control the code, quite the opposite in fact; any one single developer is always going to do a worse job of writing a correct implementation, than a collection of developers using the implementation in slightly different ways with slightly different edge cases and insights. That is the value of shared dependencies.

Your own quality control on top of that should be review, not control. By all means review all the dependencies in your tree to ensure that they are up to scratch; this will still take less time than writing your own implementation, and it will give you the extra check that you are looking for to guarantee the quality of your work.

The difference between a large and a small library is that you can not make a small one an additional dependency on a third-party developer, but shift its support and coverages tests to yourself. In a large library, I do the same with PR, helping to correct the errors found. Transferring it completely to my project is already expensive and long.

I'm afraid I don't understand what you're trying to explain here.