#471 Nested classes are not discovered by source generator

[ekspedycja]

In current implementation of the Source Generator nested classes are not discovered properly. This may be an issue in case of some of Vertical Slices approaches where feature is a class that consists of multiple subclasses.

public static partial class GetAssignedTasks
{
    public record Result()
    {
        public string ResultBlahBlah => "BlahBlahBlah";
    }

    public record Query()
        : TeamRequest<Result>
    {
    }

    public class Validator : AbstractValidator<Query>
    {
        public Validator()
        {
            RuleFor(p => p.GameId).NotEmpty();
            RuleFor(p => p.TeamId).NotEmpty();
            RuleFor(p => p.TeamName).NotEmpty();
        }
    }
    public partial class Endpoint : BaseTeamEndpoint<Query, Result, Result>
    {
        public override void Configure()
        {
            Get("assignedTasks");
        }
    }
}

Its not an issue with Endpoint and its inheritance as when class is moved outside the top level class it is discovered properly.

The PR also simplifies the approach with discovering namespaces - IMO current approach is the way around.

[nefarius]

Could you enable allowing edits by maintainers please? Trying to commit a minor style fix, thx. See below.

[nefarius]

Could you eliminate the one redundant space at the start, thanks 😎

[ekspedycja]

Done

[dj-nitehawk]

@nefarius

is this PR ok to be merged other than the space thing?
i didn't look at it properly, but saw that the exclusion list was removed.
is that alright?

[nefarius]

The exclusion list got removed; the matching of derived classes is now based on searching for the interfaces including the FastEndpoints namespace, I still wanna test it in one of my projects but IMHO unless it is not desired to allow someone to create endpoints in a Microsoft, NuGet etc. namespace it should work alright.

@dj-nitehawk need your brain here; could that lead to any undesired side-effects I forgot about?

[dj-nitehawk]

yeah that should be alright.
give it a test run in your project and give me the final go ahead for merge.
no rush, next release will be in about a week or so.

[nefarius]

I have a project where I deliberately had to avoid "NuGet" in my namespaces, this will be perfect to see if I can now do that 😎

[dj-nitehawk]

@ekspedycja @nefarius

did some testing with this today and it was only discovering public types.
most of my endpoint classes are internal sealed. committed a change that will transform internal types as well.
i'll merge this PR now as it seems to be performing good.

@nefarius if you find any issues in your project, do open up a new issue and we'll look in to it then.

thanks a lot @ekspedycja for this 🙏

[nefarius]

@nefarius if you find any issues in your project, do open up a new issue and we'll look in to it then.

Works!

namespace FastEndpoints
{
    public static class DiscoveredTypes
    {
        public static readonly global::System.Type[] All = new global::System.Type[]
        {
            typeof(global::NuGetCachingProxy.Endpoints.CatchallEndpoint),
            typeof(global::NuGetCachingProxy.Endpoints.PackageDownloadEndpoint),
        };
    }
}

👏

[ekspedycja]

I'm glad I was able to help 🙂

One thing came to my mind but I had no chance to test it. Currently the list of available types includes FluetValidation.IValidator. I am not quite sure if this may be an issue if some externals packages implement their own Fluent Validators. In the other hand the generator is run on users code not on imported nugets so this should be fine - or maybe a good idea to test that.