Yep, I agree with that. I had seen the post by Thomas Fuchs making the case for a better standard library. He makes some very good points. I appreciate that it can be a bit frustrating to have to depend on such small modules as left_pad in JavaScript, when coming from a language like Ruby (with a much better standard library), where you have all of that built in.
I also read Brendan Eich’s reaction to the call for a better standard library. It seems that the reason that this isn’t currently an option is that the language isn’t maintained by a single person or pair of people who design well (like the founders of Unix did, or the creators of Perl, Python, and Ruby do). Instead, “You have a bunch of people from different companies. They’d do a terrible job if they were in charge of building a big standard library.” — which I guess is a fair point.
There may be a certain element of naiveté about this next comment, but here goes anyway… If something like left-pad is so small (12 lines was it), and seemingly unlikely to need to change, why would you make it a dependency, rather than just rolling it into the larger piece? Is this just down to the way certain pieces of OSS are inter-licensed?
It feels rather like a carefully crafted spiderweb, you know, the kind that gathers dew and glows in the morning light, only to have it torn to shreds under the hooves of a passing elk…
It’s further reaching than that. The JS ecosystem as a whole(npm) has glorified small modules and these philosophies are making their way to the front-end too.
I was thinking more of a particular product making use of it as a dependency - let’s for argument sake say React is using something like left_pad (could be anything in reality) as a part of its build, wouldn’t you just pull that into the product core and take away the dependency? Given the size of it, and the limited scope of its functionality, it’s not likely to change much I’d have thought, so would seem a low risk route to take. For the impact left_pad had though, maybe it is significant enough consider for the standard library - in truth I’ve no idea what it does, apart from something lots of people relied on.
Pads a string with an specified amount of characters (which defaults to space)
leftpad('foo', 5)
// => " foo"
“foo” is 3 chrs in length. 5-3 = 2, so it adds two spaces to the start of the string.
leftpad('foo', 5, '-')
// => "--foo"
etc …
Ah gotchya. Yeah, there’s no real reason (I can see) not to do that and I think it’d make sense.
The reason that didn’t happen (as Mark mentions) is due to the fact that the small module philosophy has been glorified and is the current standard way of doing things.
I’ve not set up a test for this, so am not immediately sure what I’d get, but what does it do if you supply a pad value of less than the string length. Presumably nothing, with no error?
I feel like everyone’s focusing on the wrong thing. The kerfuffle that happened had absolutely nothing to do with the size of the dependency. If jQuery or lodash disappeared from NPM, we’d suffer exactly the same problem. What we really need is a guarantee that a dependency won’t disappear.
I agree that the size of the dependency isn’t the biggest problem but when micro-packages are glorified the number of dependencies goes through the roof.
Each dependency is an external piece of code that you have to know about.