Comment by bob1029
2 hours ago
Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
In about 99% of cases, I have the option to pick between Microsoft, a 3rd party or myself. I'm picking that first option every time I can. If M$ can't handle it, I'm hand rolling it.
Dapper remains the only constant 3rd party dependency in my projects. I don't know how much longer this will last with LLM assistance. The frontier models are very good at writing repositories over arbitrary sql schemas with low level primitives now.
> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this.
This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing small things (left pad) rather than larger utilit libraries maintained by a larger community.
A larger community contributing to a larger library would mean that a larger community feels responsible and checks it.
That small package mentality a trace to web usage: JavaScirpt code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
With server side Node.js this lead to tons of dependencies ... which is worsened by npm allowing to have multiple versions of the same package in parallel. So if something depends on leftpad 1.0 and something else in leftpad 1.1 both are fetched and both are available.
This has been improving recently; one large project built on several heavy libraries that I've been supporting since 2018 currently installs ~180 dependencies without loss of functionality compared to how it worked, and what it depended on, back in 2018.
IIRC 6 years ago the full dependency tree congealed into more than 2000 packages. One small example is React itself:
- 5 deps: https://www.npmjs.com/package/react/v/15.6.2
- 0 deps: https://www.npmjs.com/package/react/v/19.2.6
Another is switching from create-react-app with its hundreds of transitive dependencies to vite, which, according to the test I've ran just now, currently has 15. Etc.
> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client.
Which is another part of this entire insanity:
Browsers are already <<huge>>. They're also built by <<huge>> companies companies that collect <<tons>> of analytics.
You'd think at this point they could present a proposal for a rock solid extended JavaScript standard library that would be based on actual website usage and would be comparable to what Java, .NET offer, obviously only keeping the parts that would be applicable to the web.
It sounds crazy but I think the Chrome installer is 150MB and an entire decent stdlib these days would probably be 1-5MB...
The web api is actually extensive. I can understand complaints about it being not exactly approachable, and some wanting a cleaner abstraction, but there’s no way that it is small. Most issues is about people wanting to download a small library than just vendoring the small snippet of code.
The other issue is the sheer amount of tooling and “plugins” for those toolings. Like the babel and webpack situation, which is truly kafkaesque.
How large a project do you typically use dotnet for?
IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
> How large a project do you typically use dotnet for?
The largest dotnet project I am responsible for has around 50 megabytes of source files sitting on its main branch right now. If you include the generated WCF references it's probably closer to 100 megabytes.
I don't think going commercial has been that impactful. It sucks, it betrays the spirit of open source but whatever. A few examples:
- FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here.
- Moq lost trust - we have NSubstitute
- AutoMapper and MediatR have been widely misused anyway
- Maybe MassTransit is a real bummer?
Switching to the forks/alternatives is still time and effort, often a lot of it.