thanks for the review @derrabus

Thank you for your contribution. The main reason why I'm blocking the merge right now is that the PR does not contain a single test which is a blocker for a new feature.

It's a WIP to get an idea of how to implement it.
I won't make too much effort until we get the idea approved :-)

After reading the code and the linked issue, I still have no idea what problem you are attempting to solve and what Composer has to do with it. Tests are not just some icing on the cake that we can add when we have time for it. Tests also help a reviewer understand how your new feature is meant to be used. Tests could've helped me understand your PR.

I'll try to rephrase what the ticket says by comparing what the framework allows and what I'm proposing.

current implementation: we can import all classes from a namespace+path, then we put globs to exclude some of them

proposal: we import all classes tagged as services we can found in the project's composer.json file under the autoload > psr-4 section

the problem: make it easier to configure applications that use advanced folder structures (hexagonal architecture, ddd)

Anyway, what does this configurator do?

• Is it loading services from a composer package? If so, that package should probably ship with a bundle instead.

No, it reads the project's composer.json file and ties the framework with what is declared there

Today we must declare the namespace in both composer.json and the config/service.(php|yaml) file.

• Is Composer used to discover classes? If so, what's the benefit over the PSR-4 autodiscovery feature that we already have in the DependencyInjection component?

The current implementation does read autoload > psr-4, but I'm not sure if it's the best solution.

The name ComposerConfigurator may cause some confusion here.

The main point for the moment I think is to determine whether the problem the issue (and this PR) tries to solve is relevant enough or not.

So, you're basically solving two independent problems:

• Fetching namespace to filesystem mappings from composer instead of configuring it explicitly.
• Replacing the exclusion of certain files with an opt-in mechanism via attribute.

The former could indeed be useful if done right. We've just added a PSR-4 discovery feature for the routing component where we had to configure the mapping explicitly again. The latter has been discussed rejected in the past I think.

Anyway, I would strongly recommend to pick only one of the two problems. They both come with a certain complexity we should not underestimate.

Fetching namespace to filesystem mappings from composer instead of configuring it explicitly.

I don't see the problem with the current way. Actually, I see the current way as superior since it allows selecting a subset of all possible classes known by composer. So I'm not convinced by this aspect.

Replacing the exclusion of certain files with an opt-in mechanism via attribute.

This I like it. I'd recommend focusing on this alone, at least as a first step.

Let's close this PR. There hasn't been any progress after the initial review which was > 1 year ago.

@renanbr Feel free to open a new PR if the topic is still relevant to you.