For exactly this reason, when I write software, I go out of my way to avoid using external packages. For example, I recently wrote a tool in Python to synchronize weather-statation data to a local database. [1] It took only a little more effort to use the Python standard library to manage the downloads, as opposed to using an external package such as Requests [2], but the result is that I have no dependencies beyond what already comes with Python. I like the peace of mind that comes from not having to worry about a hidden tree of dependencies that could easily some day harbor a Trojan horse.
I always force myself to do this too. The only 3rd party python library I regularly use is "requests" basically —a dependency that comes with its own baggage, see the recent controversy about "chardet"— but I go out of my way to grab it from pip instead installing it via pip. :-)
Something like this:
try:
import requests
except ImportError:
from pip._vendor import requests
This is good wisdom, and I think this is a strong reason why language and runtime developers should ensure their standard library is (over)complete.
Go does this well, to the point where a lot of people in the community say "you don't need a library" for most use cases, only for e.g. database drivers. This is contrary to what a lot of developers believe, that they need e.g. a REST API library or enterprise application framework as soon as possible.
.NET is great because you use a FOSS library and then a month later the developer changes the licence and forces you to either pay a subscription for future upgrades or swap it out.
The amount of third-party (non-testing related) dependencies needed for most .NET applications is very manageable and the dependencies themselves (generally) don't come with further third-party dependencies (especially now that JSON serialisation is native).
This means that for most applications, the developers know exactly which dependencies are needed (and they are not hidden away in large folder structures either, the dlls are right next to the assembly).
C#/.NET is a good example showing no matter how much programmers you have, how much capital you hold, it's still impossible to make a 'batteries-included' ecosystems because the real world is simply too vast.
Say what you want but I can write a production backend without any non-Microsoft dependencies. Everything from db and ORM to HTTP pipeline/middleware to json serialization to auth to advanced logging (OTel). Yes, sometimes we opt for 3rd party packages for advanced scenarios but those are few and far between, as opposed to npm/js where the standard library is small and there is little OOTB tooling and your choices are to reinvent a complex wheel or depend on a package that can be exploited. I argue the .NET model is winning the new development ecosystem.
I agree with you, almost all .NET code I write is within the .NET framework, yet when I look at C# repos, it's disheartening to see so many (new) projects just NuGet this NuGet that.
We have text.json now but I still see people use Newtonsoft JSON.
There's old repo's out there that should be archived and deprecated, yet I see new games use it when the repo is very questionable with automated whitespace or comment commits to keep up the appearance that it is still being maintained[0].
Right now I'm working on a Golang project and the dependency tree is a nightmare to say the least, I hope to be able to rip out the parts I don't need and compile it without the massive bulk that I do not need.
It's very frustrating to want me to trust the author, who trust the author, who trust the author. When I doubt they even audited or looked at what they imported.
I generally limit myself to what's available in my distribution, if the standard library doesn't provide it. But normally I never use requests because it's not worth it I think to have an extra dependency.
This might hold true for easy deps, but (let's be honest who would install is promise) if you have complex or domain specific stuff and you don't have the time to do yourself or the std lib does not have anything then yeh you might still fall into the pit, or you have to trust that the library does not have an supply chain chain issue itself.
> I go out of my way to avoid using external packages.
I go out of my way to avoid Javascript. Because in all my years of writing software, it has 100% of the time been the root cause for vulnerabilities. These days I just use LiveView.
[1] https://github.com/tmoertel/tempest-personal-weather
[2] https://pypi.org/project/requests/