3 ms·
Rather than force NPM to take a dogmatic approach, what about considering what a reasonable, pro-all-users "no" solution looks like? Node already has tools lik
by ivraatiems 5y ago
Rather than force NPM to take a dogmatic approach, what about considering what a reasonable, pro-all-users "no" solution looks like?
Node already has tools like audit that tell you if there's problems of various kinds with your packages. (The quality of audit, and NPM in general, is pretty poor, but this could apply to many package managers, NPM is just the current example.)
So sure, allow people to pull their packages. But require a 60-day "cooldown" period where the package is still available and comes with a warning every time it's downloaded that on such and such a date it will be deleted, by request of its creator. The note could include a message from the creator and links to viable replacements.
Also, assuming licenses permit, do NOT delete any existing copies of the package or break when the user tries to update again later. Just keep sending warnings until the cached package is removed.
Finally, make it clear to authors of packages that if they submit to NPM, this is what will happen if they choose to remove their package.
What would be wrong with such an approach?
- hmsimha 5y agoWhat if the package bundles were stored on IPFS? They would be hash-addressable, and also verifiable (no danger of package hosts inserting malicious code), and npm would just be responsible for building, verifying that a given bundle based on the package source at a given commit/version builds to a package with a given hash. Then its main role to cli users would be to provide the index. Once uploaded, content could not be removed, so maintainers couldn't pull packages, though npm could de-index certain builds if they were found to contain malicious code.