Programming

17534 readers

248 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

snowe

Ategon

[email protected]

128

When "Everything" Becomes Too Much: The npm Package Chaos of 2024 (socket.dev)

submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/programming

38 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] RonSijm 16 points 9 months ago (2 children)

This situation is due to npm's policy shift following the infamous "left-pad" incident in 2016, where a popular package left-pad was removed, grinding development to a halt across much of the developer world. In response, npm tightened its rules around unpublishing, specifically preventing the unpublishing of any package that is used by another package.

This already seems like a pretty strange approach, and takes away agency from package maintainers. What if you accidentally published something you want to remove..? It kind of turns npm into a very centralized system.

If they don't want to allow hard-removals because of this, why not let people unpublish packages into a soft/hidden state instead? Maybe mark them with the current dependencies, but don't allow new ones - or something

I prefer the approach of Azure DevOps more. When you publish any nuget, or npm into their system, the entire package dependency tree is pulled in and backed up there. So you don't rely on NPM anymore to keep your referenced packages safe

[–] [email protected] 3 points 9 months ago

Cargo.rs also has no option to unpublish a package. There is however the option to yank a package which disables the inclusion in new projects by the automated dependency resolution. If the version is entered manually it will still be used.

[–] [email protected] 1 points 9 months ago (1 children)

I feel like you could also give the maintainers the power to "re-publish" using a different verified maintainer so that if such a thing does happen, it can be reversed without input from the maintainer that originally pulled it. I don't know enough about the system to really know if this is a good idea tho.

[–] [email protected] 7 points 9 months ago

Yeah then you’ve got security problems. If a maintainer pulls a package, you wouldn’t want some rando able to push a new one in its place.