This is why lately I’ve been a fan of very extensive standard libraries (like Crystal has) - its like having a huge repository but vetoed by the same team and without any of the package management drawbacks.
It is tested? Edge cases figured out? Essentially for this code?:
return start + val * (end - start);
> Saves you time.
There is something really wrong if finding a package to do this niche thing is faster and more optimal that just writing out that one line of code.
There are costs to these micro-libraries that outweigh the gains. This code is trivial; there aren’t really edge cases to be worked out.
Nope, it doesn't guarantee its invariants. This would pass all the tests and yet returns a value out of bounds:
> s = 1e12
1000000000000
> e = 1e-8
1e-8
> s + 1.0 * (e - s)
0Same could also be said for build times not to mention security issues should one of your micro-dependencies be hijacked.
Having had some involvement in the early days of node, I had imagined there being something like the Python stdlib. When the npm world grew, I thought "oh, that's pretty cool. It's neat how npm can handle multiple versions of the same package."
Now, I'm in absolute agreement with you. There are definitely downsides to a large standard library, but I think the upsides are worth it if that library is maintained.
If you've ever used a code dependency, you are a target for malicious code. That's just how it is.
In this case, using small packages like this helps in...
1. Reliability - these packages are typically 100% unit tested
2. Convenience
3. Reduce codebase size. I can't imagine having to copy paste every little small function into a mega utils file.
``` exports = module.exports = trim;
function trim(str){ return str.replace(/^\s|\s$/g, ''); }
exports.left = function(str){ return str.replace(/^\s/, ''); };
exports.right = function(str){ return str.replace(/\s$/, ''); };
```
Here's a paste: https://pastebin.com/kBHprdyj
Javascript would offer a library for every single option, variant and logical operator for a UNIX command. Combinatorial explosion will devour the web. It already destroys dev laptops anyways when downloading something via NPM.
It seems like the only reason these packages get any significant downloads is when one of them gets depended on by a big package, causing the entire dependency chain of the user’s little packages to be downloaded.
With 8.6 mil downloads and 71 dependents...
You could replace the regexp with something matching everything and they would still pass.
We can measure the depth of a black hole.
JavaScript is just amateur hour, and these things are going to keep happening. It's pathological.
The first only works with arrays and array-like objects.
The second works on objects and arrays, but it iterates over all enumerable properties, so you don't want really want to use it for arrays. It's also made a lot less useful because it only iterates over properties, not keys.
The third finally provides some sanity, but it's only been around since ES6. Before that, lodash's each method was the most reliable way to iterate over a collection, be it an object or an array.
Just because you don't know the reason for something doesn't mean there isn't one.
That said, you can use `Object.keys`, `Object.values`, or `Object.entries` if you want to iterate over objects that don’t implement `Symbol.iterator`, so if you only need `_.forEach` there is no reason to pull in any libraries.
Object.entries(object).forEach(([key, value]) => {
// ...
});Yes, this one. If the object is an Array. According to whatever test they are using for that.
Lodash includes a reimplementation of Array.prototype.forEach because mistakes were made. It also works on other objects because other mistakes were made.
We all make mistakes. But just because there is a reason for something does not mean there is a good reason.
I don't want to ban you, but when accounts keep doing this, we kind of have to.