I think there's a low-effort solution to GP: Just split off the notification function for now.
There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.
> Make a huge number of tiny libraries and people complain about left-pad.
Making a number of similar libraries that would be better served as some sort of common set (i.e. even at the most basic level, right pad and left pad can be in one thing, RIGHT?)... but at the same time it's a particularly bad example because the overall behavior of that tread was a form of influencer growth hacking.
that said, I think something like a 'notification function' falls into the category of 'boundary API' and those should always be segregated where possible for security as well as maintenance purposes for all parties.
> I think there's a low-effort solution to GP: Just split off the notification function for now.
100% agree that some of the functionality could be decoupled, and either the project should provide independent helper libs or at least do a better job of documenting the interfaces.
In this specific case, the notification interface is documented (and there's client implementations in a bunch of languages).
There's a dilemma here: Make a huge number of tiny libraries and people complain about left-pad. Make a monolith and this type of attack can happen. If left-pad is more preventable, let's go that way. The fact that C and C++ have tons of overhead in producing a package is their problem to deal with through better tooling.