So the “prank”, as called in the article, used the same flaw that allowed someone to do it last January. His apology appears deleted along with the repo.
Was there a legitimate purpose or is he just a troll?
Was there a legitimate purpose or is he just a troll?
Call attention to a real issue that should be solved by the ecosystem so that people cannot do it in the future? In my opinion it is not useful or even sane to expect people to just _not_ do annoying things if you develop systems that allow people to do things that annoy you with them. Design and build systems that assume people will be trolls, and make it so people cannot so easily troll you with them. Failing that, there's nobody to point the finger at besides the person or people who made it possible.
The pranksters "thought it would be funny" (one is quoted as saying in the article).
How crazy that there’s not like a limit or some kind of basic check to prevent the upload or something?
Honestly at this point it seems to be a failure on NPM’s part. People should really direct their anger to the maintainers at this point
And it's not really arbitrary. You can count the dependency tree of every package and get the P99, exclude joke packages and get the max of the rest. Set the limit around there with an error message to open a bug if you need more, grandfathering legit old large packages with some kind of admin-level exception.
The number of people actually needing more will be incredibly tiny. Service those folks individually to avoid pain.
When it's a staffing limit the question becomes less arbitrary.
The person made thousands of modules that look like `@everything/sub-chunk-{id}`, each depending on N modules. Those sub-chunk modules, together, depend on all NPM modules. Whatever upper limit you come up with, anyone can do this by setting N to your upper limit.
The problem here isn't that you can create modules that depend on other modules. If there's a problem at all, it's that the NPM's yank policy could be improved.
And I agree about yank! I just think you could implement multiple reasonable solutions here
That they rolled all of those submodules into one big everything package is just a gimmick, not a source of the problem.