Can we simplify package management with Central Package Management?

bUnit-dev / bUnit

bUnit is a testing library for Blazor components that make tests look, feel, and runs like regular unit tests. bUnit makes it easy to render and control a component under test’s life-cycle, pass parameter and inject services into it, trigger event handlers, and verify the rendered markup from the component using a built-in semantic HTML comparer.

https://bunit.dev

MIT License

1.12k stars 104 forks source link

Can we simplify package management with Central Package Management? #723

Open egil opened 2 years ago

egil commented 2 years ago

CPM looks like an opportinuty to clean up our .csproj and directory.build.props files, at least to some extend. https://docs.microsoft.com/en-us/nuget/consume-packages/Central-Package-Management

linkdotnet commented 2 years ago

Nice feature. Did not know this is around. A few things we have to consider:

It is only a small help in my eyes. In theory we could also now add all dependencies to our root Directory.Build.props and have the same effect with less clutter in the csproj. The rosyln compiler will remove anyway every assembly which is not used in the code anyway (via static analysis).
It only works on VS 2022. I personally use this as well as Rider (as you saw :D). I am not sure if we introduce problems for people which like to contribute and have some other tooling. Supporting both ways seems not what we want to do :D
All of that does not matter because there is major blocker: It requires .NET SDK 6.0.300. So could introduce major issues on CI. At least we have to refactor how we setup .NET-SDK stuff.

But I'd like to keep this open to see where this is going in the future. Cool thing you found there Egil ;)

egil commented 2 years ago

If it doesnt work with Rider/the command line, then yeah, lets wait a bit with this.

linkdotnet commented 2 years ago

Just to have some documentation about our findings: This might be something for version 2.0. Currently the support of < .net6 will block that feature.

Let's assume we want to build .net5 assembly. We can do this with everything equal or higher than the .net5 SDK, but unfortunately that does not work with running tests. The test-runner has to come from the same SDK version as the assembly under test.

That means we can't simplify our CI/CD pipeline to use the following:

- name: ⚙️ Setup dotnet versions
  uses: actions/setup-dotnet@v2
  with:
    dotnet-version: |
      6.0.x # Only latest stable release - can build everything <= net6.0 but not test != net6.0
      7.0.x # Only latest preview release - can build everything <= net7.0 but not test != net7.0
    include-prerelease: true

Another issue we might run into is dependabot as I am not sure whether or not they support that feature.

linkdotnet commented 1 year ago

NuGet had a juicy update: https://devblogs.microsoft.com/nuget/announcing-nuget-6-4-signed-central-delivered/#use-a-single-packagereference-everywhere-with-globalpackagereference

Still something for v2.

linkdotnet commented 2 months ago

Conclusion: We can go ahead with this feature as tooling support is given.