A more portable Stryker.Core on NuGet

[rachied]

I'm working on the Stryker Playground, a browser demo of Stryker.NET powered by Blazor WebAssembly. The playground is using a fork of Stryker.Core with some classes and (large) dependencies stripped. The fork relies on:

• DotNet.Glob
• Microsoft.CodeAnalysis.CSharp
• Microsoft.Extensions.Logging
• Serilog

I would like the Stryker Playground to depend on mainline Stryker instead of forking, that way the mutants and the mutation placing capabilities get updated whenever Stryker.NET releases a new version.

For that we should:

• Create a new Stryker.Core.Common csproj
• Make Stryker.Core depend on Stryker.Core.Common
• Lift the common logic from Stryker.Core to Stryker.Core.Common
• Add pipeline task to distribute Stryker.Core.Common on NuGet

Questions

• Does the Stryker.Core.Common name make sense, or should the Core part be omitted?

[rouke-broersma]

Your proposal seems to be fairly focused on making this work for the Stryker playground. While I share the wish for a more portable and extensible version of the Stryker core, this needs to be thoroughly designed keeping the bigger picture in mind. Perhaps we should discuss this offline.

[richardwerkman]

If we do this we should also look into disconnecting versions of our packages. Right now dotnet-stryker and stryker are kept at the same version. But we only track semantic versioning for dotnet-stryker. Breaking changes happen all the time in stryker. Once we introduce a new package for common or domain this could have a more stable version.

[rachied]

Discussed this with @rouke-broersma and @richardwerkman over a call. Recap:

Making the Stryker core functionality more portable has been a wish for a longer time and is not as straightforward as my initial proposal suggests. Parts of the Stryker.Core need to be modularized into individual packages to best serve all use cases in the future (when, for instance, building VS extensions for Stryker). It will affect the current versioning and deployment workflows, as well as the way things are referenced internally (does Stryker become a consumer of its own libraries?)

For that reason, this has been proposed as a graduation project at Info Support and may be picked up by an intern in the very near future.

In order not to disrupt that assignment, I'll hold off on any implementation of this. I will follow up with a more detailed inventory of which parts of Stryker Core I'm using in the playground so it can be tracked in this issue.

[rachied]

On a related note: I attempted to make direct use of the current Stryker by pulling in the NuGet package. It seems the nuget is missing some assets because it shows the following error:

[Notification][Install] Install failed (project: Stryker.Playground.Domain, package: stryker v3.9.0)
Package restore failed. Rolling back package changes for 'Stryker.Playground.Domain'.
Unable to find package Stryker.DataCollector. No packages exist with this id in source(s): nuget.org
Unable to find package Stryker.RegexMutators. No packages exist with this id in source(s): nuget.org