this post was submitted on 22 Dec 2025
78 points (96.4% liked)
Technology
77873 readers
4436 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This truly has grown past a JS problem. NPM was kind of the first time dependencies were installed by the project rather than through the OS. But nowadays this has become the norm, golang, rust, and to an extent python also work by installing dependies directly from git for the most part. 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 model.
Can’t they make dependencies something that get checked at launch time? The executable says “I have the following external dependencies pulled in. “ and then if a version is blacklisted, the executable should stop and throw an error saying exactly what component was blacklisted and stopped it from running.
Why can’t we have executable declare their dependencies at launch time to the OS?
That's essentially how most distributions of Linux and Unix work. You package an app with a list of depencies like "libcaca >= 1.2.3" and that's that. If that dependency isn't available in the distro you need to have that packaged (and thus have a maintIner for said package) forst. The distro's package maintainers are responsible for keeping an eye on the upstream sources and provide reviews. Then this sort of crap like NPM came along and it became popular for devs to package their own dependencies.
Maven entered the room.
I'm not super familiar with Maven so I could be wrong, but doesn't Maven still pull depencies from upstream? That doesn't fix the problem. Having depencies packaged in the OS means there is in theory some level of overview and review by the package maintainer(s).
I am on my phone, which is a bit too long to explain, but there are multiple facets to how NPM is worse than most packaging systems out there. There are enough on the web for you to browse and learn, if you are really interested to know more.
But, here, I quoted a little something from Brian from Sonatype.
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.
A few operating systems (e.g. OpenBSD) do actually (try to) enforce using
pkgfor Perl dependencies, due to Perl being "system Perl" instead of "packaged Perl".Debian does as well for anything that is packaged. For python, golang, rust, etc as well.