15 comments

[ 2.6 ms ] story [ 48.6 ms ] thread
Yikes, it's one thing to stop development of somethign but another to intentonally do damage to thousands of people, big companies and small one person webdev shop. This guy probably can't be sued because of opensource, but he should be shunned in the future by open source advocates and just the public in general. Why would anyone hire him unless it's to run an antifa/right-wing website?
This reflects more on the state of modern web development where so much value and important sits on top packages run by individuals who have 0 obligations and infinite power.

Either we need to consider all non corporate packages as a threat, or take away power from the package developers so they can't just yank a package retroactively from peoples software. Perhaps keeping a local mirror will become standard rather than relying on an always available online version.

I feel for him and his mental state. I get the feeling he feels betrayed by huge corps using his software are making millions, whereas he still has to rely on measly donations for survival. Unfortunately, that's not how open source has worked so far. Hypothetically if he gets paid a 100k, does he plan to share it with the other contributors?

I don't think there is a right or wrong here, but relying purely on independent open source software as a career is a recipe for disaster. It sets up unrealistic expectations, and probably burnout and heartbreak.

The only thing that seems clear is that post about committing the whole node_modules folder to git was correct. Despite all the ridicule HN gave it.
Or you could use a lock file
Lockfile doesn't help here. The packages were yanked from the repos. The lockfile will tell your package manager to try to download a package that does not exist. Checking in the entire node_modules folder saves you since you don't need to fetch any external files.
Good practive here is using package cache. It is not that hard to install, and your CI builds will save tons of trafic for you and for global package repos (Github, NPM, Packagist and so on)
Indeed, Go would not have failed here because the global package cache keeps deleted repos. Module authors cannot effect this

Other languages require you to run a cache and set proxy config up for the builders

An unfortunate solution because it might be the right one at the cost of maintainability and repo size
YARN v2 onwards has Zero Install mode where you _do_ typically commit a cache folder to source control: https://yarnpkg.com/features/zero-installs

It can be a little tricky to get working with some tools, but it is very fast and doesn't take up as much repo space as you'd expect since the approach is much more efficient than node_modules.

I don't understand why publishing a new version of a package breaks 1000000s of existing apps?

Do you not depend on a specific version? Do you not use checksums for dependencies?

Because by default in NPM you reference version ranges using ~ and ^ operators. For sure in a corporate environment no one has time to polish dependencies to specific versions.