-
-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source Generator: Initial Version #1300
Conversation
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 |
f5e1a0d
to
b682d79
Compare
That would've been smart - I can do that once I am in the shape of the Generator I feel confident with. |
@linkdotnet ToDo: Add to docs with all limitations and use cases. Including setup and what not |
There are still some open points - but they are secondary and "easy" to challenge.
|
dbe947e
to
584d57a
Compare
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; }
} |
Todo: Move AddGeneratedStub into generator EDIT: The generator can't directly reference 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. |
3dc5f35
to
b3ff9e6
Compare
src/bunit.generators/Web.Stubs/AddStubMethodStubGenerator/AddStubGenerator.cs
Outdated
Show resolved
Hide resolved
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 |
Are there any things open we want to tackle on this PR? |
src/bunit.generators/Web.Stubs/AddStubMethodStubGenerator/AddStubGenerator.cs
Outdated
Show resolved
Hide resolved
src/bunit.web/Extensions/StubComponentFactoryCollectionExtensions.cs
Outdated
Show resolved
Hide resolved
src/bunit.generators/Web.Stubs/AttributeStubGenerator/StubAttribute.cs
Outdated
Show resolved
Hide resolved
Did we come to a conclusion on the release package with preview tag in the version number vs. using the experimental flag in csproj? |
Co-authored-by: Egil Hansen <[email protected]>
The new Experimental thing is an attribute either on a method, class or assembly. Nothing we can add to the csproj itself. [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 That said - probably we can use tags for the time being. |
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. 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:
This ensures that build dependencies between libs is maintained, and that docs are in sync. |
Not sure how easy that works with ngbv (with "sub" version.json). So let me know, if there are any open points regarding the generator. |
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 |
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. |
Let me add the nuget link to the readme and docs before we merge it - should add some more traction |
Done - see last commit |
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.