I agree though, that the challenge is different in a compiled language (from JS/PHP), and when dependencies get specific you might be out of luck (when .NET Core was announced I had a hard time following Microsoft's own tutorial because minor revision was different between two key packages)
At least the granularity of Nuget packages is not at npm-level fineness, although it does sort of feel like it is trending in that direction.
I have no knowledge of how NuGet works but is there anything in NuGet that is stopping the developers from writing/using single line packages?
. NET, however, has an excellent stdlib, so in practice you simply do not get packages like this.
It doesn't matter what your plans are. If Microsoft forces you to move on to something like .NET Core you will. Eventually, when it comes to ASP.NET there will no difference between the core and the non core version.
This confirms my decision. I'm sure it will be nice once it's all sorted out. The money quote for me is below:
Since our goal was to represent any .NET platform we had to break it up into smaller NuGet packages. This works reasonably well if all these components can be deployed with the application because you can update them independently. However, when you target an abstract specification, such as PCLs or the .NET Standard, this story doesn’t work so well because there is a very specific combination of versions that will allow you to run on the right set of platforms. In order to avoid that issue, we’ve defined .NET Standard as a single NuGet package.