Source Generator: Initial Version

[linkdotnet]

Closes #1297

The idea is to have an Attribute to annotate a stub. The general sentiment is to give fine-grained control so that users still have the ability to invoke event callbacks in their stubs.
So if a parameter is already defined, we don't have to do the work.

Open questions are annotated or are linked in the issue.

[egil]

I think it's going to be easier to see what's going on if you start by renaming the existing internal generators project to bunit.generators.internal and merge that into main. Then create a PR without those changes.

[linkdotnet]

I think it's going to be easier to see what's going on if you start by renaming the existing internal generators project to bunit.generators.internal and merge that into main. Then create a PR without those changes.

That would've been smart - I can do that once I am in the shape of the Generator I feel confident with.
If it is fine for now, you can easily just checkout the new StubGenerator.cs under Web.Stubs. Everything "that moved" can be ignored ATM

[linkdotnet]

@linkdotnet ToDo: Add to docs with all limitations and use cases. Including setup and what not

[linkdotnet]

There are still some open points - but they are secondary and "easy" to challenge.
Open:

• A nice readme.md (also for NuGet)
• Adding docs (probably under a new section - we might add more such things like the testing-library)
• Explaining how to make it work (As we need the interceptors stuff in the clients csproj)
• Some more tests might be nice. Especially with more components.

[linkdotnet]

Here are the generated files:

CounterComponentStub.g.cs:

namespace System.Runtime.CompilerServices
{
	[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
	sealed file class InterceptsLocationAttribute : Attribute
	{
		public InterceptsLocationAttribute(string filePath, int line, int column)
		{
			_ = filePath;
			_ = line;
			_ = column;
		}
	}
}

namespace Bunit
{
	static class InterceptorCounterComponentStub
	{
		[System.Runtime.CompilerServices.InterceptsLocationAttribute("/Users/stevengiesel/repos/bUnit/tests/bunit.generators.tests/Web.Stub/StubTests.cs", 8, 22)]
		[System.Runtime.CompilerServices.InterceptsLocationAttribute("/Users/stevengiesel/repos/bUnit/tests/bunit.generators.tests/Web.Stub/StubTests.cs", 19, 22)]
		public static global::Bunit.ComponentFactoryCollection AddGeneratedStubInterceptor<TComponent>(this global::Bunit.ComponentFactoryCollection factories)
			where TComponent : Microsoft.AspNetCore.Components.IComponent
		{
			return factories.Add<global::Bunit.Web.Stub.CounterComponent, Bunit.Web.Stub.CounterComponentStub>();
		}
	}
}

InterceptorCounterComponentStub.g:

namespace Bunit.Web.Stub;
public partial class CounterComponentStub : Microsoft.AspNetCore.Components.ComponentBase
{
	[global::Microsoft.AspNetCore.Components.Parameter]
	public int Count { get; set; }

	[global::Microsoft.AspNetCore.Components.CascadingParameter]
	public int CascadingCount { get; set; }

	[global::Microsoft.AspNetCore.Components.Parameter]
	public Microsoft.AspNetCore.Components.EventCallback IncrementCount { get; set; }
}

[linkdotnet]

Todo: Move AddGeneratedStub into generator

EDIT: The generator can't directly reference bunit.core/bunit.web - as those aren't netstandard.

EDIT 2: Done - there is no hard reference between the package and bUnit itself, but that is currently a limitation I can live with.

That is, I generate the method inside the generator, and this relies on the fact, that the user has bUnit as package.

[egil]

Sorry has been completely swamped the last week. Will try to find time to look at this during the week.

[linkdotnet]

Sorry has been completely swamped the last week. Will try to find time to look at this during the week.

Don’t worry - I am also swamped at the moment

[linkdotnet]

Are there any things open we want to tackle on this PR?
For example - adding nuspec files to have the reference to bunit.web?

[egil]

Did we come to a conclusion on the release package with preview tag in the version number vs. using the experimental flag in csproj?

[linkdotnet]

Did we come to a conclusion on the release package with preview tag in the version number vs. using the experimental flag in csproj?

The new Experimental thing is an attribute either on a method, class or assembly. Nothing we can add to the csproj itself.
That said, I tried to do the following:

[Generator]
public class ExperimentalFlagGenerator : IIncrementalGenerator
{
	private const string Experimental = """[assembly:global::System.Diagnostics.CodeAnalysis.ExperimentalAttribute("bUnit001: This is an experimental feature.")]""";

	/// <inheritdoc/>
	public void Initialize(IncrementalGeneratorInitializationContext context)
	{
		context.RegisterPostInitializationOutput(
			ctx => ctx.AddSource("ExperimentalAssembly.g.cs", SourceText.From(Experimental, Encoding.UTF8)));
	}
}

The generates:

[assembly:global::System.Diagnostics.CodeAnalysis.ExperimentalAttribute("bUnit001: This is an experimental feature.")]

In a generated file - but that is
a) weird - because generated code belongs to the code of the user and not really to use.
b) It doesn't work for me.

That said - probably we can use tags for the time being.

[egil]

Yeah that sounds good using preview tags. We need that for the query lib too.

Unfortunately that does require either a custom version.json and custom relesse login in our workflows to update it correctly, see dotnet/Nerdbank.GitVersioning#1004, or that we try minver instead of nbgv.

[linkdotnet]

Yeah that sounds good using preview tags. We need that for the query lib too.

Unfortunately that does require either a custom version.json and custom relesse login in our workflows to update it correctly, see dotnet/Nerdbank.GitVersioning#1004, or that we try minver instead of nbgv.

Fiddled around with that - we would also need a separate release branch for our "extras" plus many changes in the CI workflows.
A separate release gives also the issue of having the docs in an "invalid" state as they are driven by the "main" packages and not the extra ones. So overall that makes it a bit brittle.

Probably the easiest for the time being is to pass in a parameter to the release-workflow that indicates the package version of bunit.generators/bunit.web.query. Of course that has it's own downsides.

With unlimited resources I'd argue it's the cleanest that bunit/bunit.docs/bunit.extras live in their own, separate repository.

[egil]

Fiddled around with that - we would also need a separate release branch for our "extras" plus many changes in the CI workflows.

A separate release gives also the issue of having the docs in an "invalid" state as they are driven by the "main" packages and not the extra ones. So overall that makes it a bit brittle.

Probably the easiest for the time being is to pass in a parameter to the release-workflow that indicates the package version of bunit.generators/bunit.web.query. Of course that has it's own downsides.

With unlimited resources I'd argue it's the cleanest that bunit/bunit.docs/bunit.extras live in their own, separate repository.

I would like the following:

• Same repo and branches for all projects.
• The preview libs with different version config such that when the release workflows creates nuget packages from the release branch they retain their preview version postfix.
• All libs share the same version number.

This ensures that build dependencies between libs is maintained, and that docs are in sync.

[linkdotnet]

Not sure how easy that works with ngbv (with "sub" version.json).
But the question is, do we want to tackle this on this very PR? I would argue, no.
For now we should be fine, as we explicitly pack the projects and publish them.

So let me know, if there are any open points regarding the generator.

[egil]

Isn't the easiest solution just to release the preview packages on the main branch and skip on the stable branch. In that case we just need to update the CI workflows to also build the preview generator package and then we are done.

[linkdotnet]

Isn't the easiest solution just to release the preview packages on the main branch and skip on the stable branch. In that case we just need to update the CI workflows to also build the preview generator package and then we are done.

Added to ci.yml

[linkdotnet]

If we merge the PR, we push the package directly. I guess that is fine!!

If so, it might make sense to release bUnit itself so the documentation is also up to date.

[linkdotnet]

Let me add the nuget link to the readme and docs before we merge it - should add some more traction

[linkdotnet]

Let me add the nuget link to the readme and docs before we merge it - should add some more traction

Done - see last commit