The way I see it, there are two problems with NPM:
It can blindly run any shell command w/o the developers explicit permission.
Anyone can make an NPM module, and the community is so fractured - common tools/features are not built into the language (or a standard library or a “vetted” community library - like boost for C++)
The first issue might be solvable with things like WebAssembly. Then it’s the developer who gets to decide how far these pm-hooks will reach (both interns of filesystem, network, etc) on a per project basis.
The second will need a shift in community mindset… and all these supply chain attacks are the fuel for that. Unfortunately, it needs to get worse before it’ll get better.
The first issue is NPM specific sure, but the second is true of all the languages I mentioned. Even golang which originally had a goal of having a built in library so vast you didn’t need much depencies has devolved into a large and fractured community.
I completely agree with you on the second point. This is a problem for all languages, but maybe we (as a community) need to change the approval, reviewing process for adding new libraries and features to languages.
This isn’t going to get any better unless we revert to OS based dependencies which noone wants to do because developers want the latest and greatest.
You’re very succinct here: Developer do want the latest and greatest, even if the interface isn’t perfect, and they’ll need to refactor their code when the next revision comes out.
Languages often have much slower release cycles than 3rd party libraries. Maybe this is what needs to be improved.
There won’t be a silver bullet, but I kinda like how kubernetes handles it: release cycles are fixed to a calendar (4 times per year). New features are added and versioned as alpha, beta, release. This gives the feature itself time to evolve and mature, while the rest of the release features are still stable.
If you use an alpha/beta feature, you accept that bugs and interface changes will occur before it reaches a stable release. … and you get warning and errors, if you’re using an alpha feature, but it graduated to beta/release.
Unfortunately, many languages either make this unnatural/difficult (ie: from future import... ) or really only support it if you’re using 3rd party libraries (use whatever@v1.2.3-alpha1).
The way I see it, there are two problems with NPM:
The first issue might be solvable with things like WebAssembly. Then it’s the developer who gets to decide how far these pm-hooks will reach (both interns of filesystem, network, etc) on a per project basis.
The second will need a shift in community mindset… and all these supply chain attacks are the fuel for that. Unfortunately, it needs to get worse before it’ll get better.
The first issue is NPM specific sure, but the second is true of all the languages I mentioned. Even golang which originally had a goal of having a built in library so vast you didn’t need much depencies has devolved into a large and fractured community.
I completely agree with you on the second point. This is a problem for all languages, but maybe we (as a community) need to change the approval, reviewing process for adding new libraries and features to languages.
You’re very succinct here: Developer do want the latest and greatest, even if the interface isn’t perfect, and they’ll need to refactor their code when the next revision comes out.
Languages often have much slower release cycles than 3rd party libraries. Maybe this is what needs to be improved.
There won’t be a silver bullet, but I kinda like how kubernetes handles it: release cycles are fixed to a calendar (4 times per year). New features are added and versioned as alpha, beta, release. This gives the feature itself time to evolve and mature, while the rest of the release features are still stable.
If you use an alpha/beta feature, you accept that bugs and interface changes will occur before it reaches a stable release. … and you get warning and errors, if you’re using an alpha feature, but it graduated to beta/release.
Unfortunately, many languages either make this unnatural/difficult (ie:
from future import...) or really only support it if you’re using 3rd party libraries (use whatever@v1.2.3-alpha1).More or less. Some repositories, like CPAN and Quicklisp, are curated with more caution than others.