NPM package 'isarray' is downloaded 40M times a week
npmjs.com
npmjs.com
The first advantage to just copy-pasting is that the snippet author might update it (e.g. if he finds a faster/safer way to do the one thing his package does), and you don't have to do anything.
Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
That sounds like a security nightmare, and broken functionality waiting to happen.
How on earth have we got here?
Hundreds of thousands of untested, unaudited implementations of a roughly-similar function _could_ be far worse in terms of overall ecosystem stability and security than a small number of frequently-used (albeit yes, potentially flawed and vulnerable) micropackage dependencies.
The outcome for each micropackage may depend on how much scrutiny and test coverage is available when updates occur, and how well-defined the package's API is.
In a sense, that's not hugely different to version upgrades for other, larger library dependencies. Incremental library changes tend to be easier for developers to audit and integrate, so perhaps eventually this is a better approach?
In my opinion Microsoft (via GitHub and NPM) are likely best-placed to make significant progress on evaluating and improving the situation.
When a micropackage is updated, they're in a position where they could run continuous integration tests not just for the package itself, but also for dependent packages, to gain an early sense for the correctness and disruption potential of the change.
That kind of information would be useful to make a micropackaging ecosystem more viable and healthy, although it would also increase the ecosystem's long-term dependence on Microsoft.
At the least you want some oversight when a dependency changes under you.
Similarly, many more “principled” programmers don’t really understand many parts of our computing stack either and it did bring troubles to even the most experienced veterans in the industry.
It is always a trade-off between risk, cost, and benefit.
Otherwise you can (and should) review the update manually or using automated tools.
The first disadvantage of “micro packages” over copy-pasting is that the author might update it to do something completely different - either because the author is malicious, or because of a transfer in maintainership of the package to someone who is malicious, or because of a compromise.
First, please don't copy paste solutions. Understand them and implement correctly. Stackoverflow is not a magic library you should take books from without understanding.
> Imagine finding a solution on Stackoverflow and just being able to import foo from stackoverflow/a/12345, and when the community finds a better way to do it, your software is automatically using the new version!
Wow, I've just imagined it. Props for the great horror story, but... it's a security nightmare. You basically surrender all control over your project for almost nothing.
> The second advantage is that it's basically built-in refactoring: Code from these micropackages will not litter your code, there is a clean separation between what is your business logic vs where you just need some generic functionality.
Writing this utility in a separate code unit (namespace, project, whatever) gives exactly the same advantage. And micropackages will litter my building process / dependency tree.
I don't understand how that is a rational decision that people are making. Can anyone explain?
It's a trade off, although personally I've been bit by that enough to keep strict version numbers in my dependencies.
What a nightmare!
That seems to have happened here, though who knows across X number of browsers and whatever JS engine updates happen.
https://github.com/juliangruber/isarray/commit/1052c9d94dc87...
Why is the fact that some devs sometimes screw up one-liners of any material importance to the existence of this library?
Some devs write code with bugs, does that mean they shouldn't write code any more? Is it either you write pristine, bug-free code on the first try for everything, or else you should be relegated to the back room gluing things together built by the _real_ devs? This is such snooty behavior that I'm not surprised at all by a response like the angry dude in there. He's an asshole for sure, but he's not totally wrong in my view.
It’s deeply unfortunate that the lack of a standard library in JavaScript combined with the constraint of wanting to minimize shipped code size in a language that resisted dead code elimination for a long time led to... whatever this is, instead of a comprehensive stdlib.
I've been a JS/Node dev for years now (granted, post a time when Array.isArray was part of the standard), and if someone asked me to write isArray, I wouldn't have done it like this, and I'm assuming there is a reason it was done like this.
What I really see is a bunch of typical "I'm a cooler dev than you" posturing for people who haven't even actually looked at the code. That's a shame because there is a valid discussion to be had around how lots of teeny dependencies can make the npm ecosystem brittle, but bullshit posturing around how any dev should be able to write this one line is just false.
Still, it's a shame that the specifics of the way the JavaScript ecosystem has evolved mean that it's commonplace to bring in a <10 line dependency to mitigate an extremely core lack of functionality, rather than have a first-party—or be able to sensibly import a third-party—standard library. I can't think of any other language ecosystem where this is normal.
- [0] https://github.com/juliangruber/isarray/commit/c8601522e3136...
- [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.15/Cha...
NPM bashing is increasingly popular, and for folks that haven't had to utilize these tiny packages they probably do rightly seem superfluous. Are people abusing it? Probably. Is it being used where it doesn't need to be? Probably. Are there long-stable, rarely changed NPM packages created before `Array.isArray` was a thing, which have this as a transitive dependency? Definitely.
For anyone who imported this as a dependency, why didn't you copy-paste the five lines into your code? I'm genuinely curious.
Similarly, is your company really OK with you just pulling in a dependency and coding onward? Do you review each external dependency's license for compatibility with your company's software? Do you audit each dependency for security issues, backdoors, and other bugs? What dependencies do your dependencies rely on, and have you reviewed them, too? How do you know the dependency works as you think it should work? What is the maintenance plan for this dependency? How often do you plan to update the dependency, and when you do, do you plan to re-audit it?
As someone who has worked on safety-critical marine and aerospace applications, this casual attitude about pulling in dependencies and copy-pasting code is so foreign to me! Is this yolo attitude really how it works in the move-fast-and-break-things universe? No large company I ever worked for would allow any of this without proper vetting and reviewing--even on non-safety-critical programs. Really interesting and scary how best practices are defined in various areas of the software development world!
I totally get your point, though, and completely agree with you on more complex examples. I would not feel comfortable copy-pasting code into my system that I didn't understand or hadn't read through completely. And I avoid dependencies as much as possible.
My best thought is that it saves time to import, it saves visual lines which may make it easier to understand what is code ripe for modification and code that shouldn't be changed.
How it normally goes:
A: why does this exist it's one line?
B: people mess up one-liners all the time.
A: those people are dumb and shouldn't be programmers
How it should go:
A: why does this exist, it's one line?
B: it's not about that, it's used to easily/quickly compose with other similar functions into more complicated things like polyfill, backport, and backcompat bundles for deployment in environments that are quite a bit behind in terms of language support.
A: oh, neat, thanks!
I'd have expected most things that have to support browsers that old would be mature projects that do not get much active development.
Isn't this what babel is for?
I am not in the position to make realistic estimates, but it sounds pretty wasteful. I have worked in mobile devices space and there you need to think about about energy efficiency to have your battery last. Shouldn't the server and Web guys need to do the same to save the planet?
Not pointing to isarray in particular, but this looks like a tremendous overhead to get minimal functionality. Is isarray an exception we can ignore or a pattern that repeats in scale?
Not to mention the exclusiveness: more than 3 billion people on this planet
- have old computer and phones with limited RAM
- ...and limited storage
- ...and slow CPUs
- have slow Internet access (even in "developed" countries if you are in low-density areas)
- have traffic caps (same)
- sometimes have intermittent Internet access
- have unreliable or expensive electricity
Reminder: this is not an inevitable problem. A lot of Linux distros run just fine on old hardware, and websites without cruft are still usable.
1. https://medium.com/hackernoon/im-harvesting-credit-card-numb...
> (In an earlier iteration of this post I said that a solid content security policy would keep you (and I quote) “100% safe”. Unfortunately 130k people read that before I learned the above trick. So I guess the lesson there is that you can’t trust any thing or any one on the internet.)
Though the approach only applied to Chrome, and the post is two years old so I don't know if it still works today?
https://github.com/juliangruber/isarray/blob/master/index.js
2. Array.isArray was added to browsers in 2009-2011. The time when IE 6 was still alive and kicking. No idea when it was added to node
3. This package plugged a hole in the stdlib, so obviously people started using it
4. It does on thing, and does it well. Unix-way!
5. How is using it any different than having the same code in a 20000-line utils.js file that any project inevitably grows to have to plug holes in JS's libs?
- [0] https://chromium.googlesource.com/v8/v8/+/refs/tags/1.3.16
- [1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.15/Cha...
Each of those would cause an outroar, and it would be near-universally agreed that having a decentralized ecosystem is better than being beholden to the whims of $company. (it doesn't help that 3/5 of the companies I mentioned are Microsoft, famous for embrace-extend-extuinish)
In general, you can always avoid picking packages with deep dependency chains. That seems like a good idea to me.
Also, I think `isarray` is quite dated, but I can understand why people used to use it, since it is basically an explicit polyfill for non-browser environments.