I guess its meant to play a sick joke on some co-workers?
If you were just trying to get people to install it directly you'd go for name collisions / typos / namesquatting in your package name instead.
What you do it fork a popular package that the project uses and make some changes.
Then update the package-lock so that it points to your GitHub fork.
This file is normally ignored in PR due to the amount of line changes in there so you can have quite a bit of fun.
They could also write tutorial or stackoverflow answers linking those packages, it would definitely pass the moderation as the rest of the code would be okay and people copy/paste a lot.
Or maybe they are just assessing what's possible. (or wrote for this article)
I can absolutely assure you, we have no affiliation with these packages. We end up reporting much more malicious packages than these every single day. We wouldn't risk harming our reputation to publish three dumb packages. Just thought these were interesting in a diabolical sort of way.
Here's a English translation of the README.md in that specific repo.
> What? The notorious 996 company wants you to hit the road?
>
> Do you want to leave a small "gift" for your project before you go?
>
> Let's sneak this project into yours, and your project will have, but not limited to, the following magical effects:
>
> - When the length of the array is divisible by 7, Array.includes will always return false.
> - When it's Sunday, the result of the Array.map method always loses the last element.
> - There is a 2% chance that the result of Array.filter will lose the last element.
> - setTimeout will always trigger one second slower than expected.
> - 10% of Promise.then will not register on Sundays.
> - JSON.stringify will change uppercase I to lowercase l.
> - The result of Date.getTime() will always be one hour behind.
> - There is a 5% chance that localStorage.getItem will return an empty string.
Years ago I played around with the idea of verifying that a npm package is the same code found in the source repo [2]. Because there is often a build step, that requires trying to reproduce the building of any arbitrary package, and flagging when there is any delta between the build output and the code distributed via NPM. In more reasonable package managers, this is true by default given that you provide the source code and the package manager builds it for you ... as opposed to NPM, which just asks for the executable code directly.
1. http://github.com/ossillate-inc/packj flags vulnerable/malicious NPM/PyPI/Rubygems packages.
With package namespaces, you can call your package anything you like that sounds like you're the real thing - lodash-2, lodash-the-one-and-only, lodash-mccloud-of-the-clan-mccloud, go nuts.
But for as long as you don't control lodash.com, then you can't publish your package under the com.lodash namespace, so it's obvious you're not the actual Lodash team.
Baffles me no end. I have no idea why PyPi and Cargo and probably so many others don't do this either, it removes an entire class of supply chain risk, and also prevents people creating dumb packages just to squat on the "good" package names.
I feel bad for the poor sods who have to debug the aftermath of this, especially the "only on sundays" one
