I'm thinking in more options to avoid type the FQCN, so what about to search the form type inside registered types or installed bundles?

$ bin/console debug:form EasyAdminFormType

if there is more than one registered with the same suffix, we could display the first and print at the bottom a comment with another matches?

Failure on deps=high is normal.

I'm thinking in more options to avoid type the FQCN, so what about to search the form type inside registered types or installed bundles?

At first, I'd suggest to add the list of "preferred" namespaces to use as an optional constructor argument of the command.
Then, we might either:

1. Populate it with only core namepaces (form component types + doctrine bridge as you did here) and let bundles or users add their own.
2. Or hook in the FormPass to gather namespaces for all known types.

if there is more than one registered with the same suffix, we could display the first and print at the bottom a comment with another matches?

If there is more than one match let's show a message saying the argument is ambiguous.
In interactive mode, ask the user to choose the it from a list using a choice question.
In non interactive mode, I think we should only display the list of matches without their information.

@ogizanagi Sorry, I didn't see your last comment before submit these changes.

Last update: We use the namespace from all known form types as base to search the form type. We show a comment when there is more than one type found.

This mean, if there is at least one form type registered, its namespace will be used to find other ones not registered.

Not a blocker to me (and don't work on it right now, we need more opinions), but other debug commands are using *Descriptors to get the output in different formats (md, txt, json, xml). I'm wondering if it can be useful. It also lighten the command itself by delegating the output construction to a proper class.

The debug:container command lists all services when run without any arg.
I think it'll be great to replicate this behavior and get the full list of registered types when the class argument is not provided (and extensions?).

The debug:container command lists all services when run without any arg.
I think it'll be great to replicate this behavior and get the full list of registered types when the class argument is not provided (and extensions?).

@ogizanagi I thought on this also at the beginning, but then I gave up, because this information can be obtained by using the command debug:container precisely. So I'm not convinced the command should show these list too, even if it's related to the Form Component.

Even though, if any else votes for this, I'll be glad to implement it.

other debug commands are using *Descriptors to get the output in different formats (md, txt, json, xml). I'm wondering if it can be useful. It also lighten the command itself by delegating the output construction to a proper class.

@ogizanagi I had left this to the end, but now that you mention it, this suggestion #23694 (comment) could be the proper class to use descriptors.

Even though, if any else votes for this, I'll be glad to implement it.-

I also think that listing them all when no arg is passed would be nice, getting the same with debug:container requires some filters.

About descriptors, I think that not using them is fine. The ones which describe component specific data are in the framework (container, router, ..), using them would prevent having the command in the form component.

The ones which describe component specific data are in the framework (container, router, ..), using them would prevent having the command in the form component.

@chalasr : We could add our own in the component itself (or even just the TextDescriptor one for now and eventually add other ones later). It does not have to be handled in the FrameworkBundle ones.

Ready for me (just squashing commits).

why are the class "internal"? isn't their design clean already?
since we build a framework, we have to balance open-closed . "closing" all the time means increasing the risk for users to ignore the annotations - and reduces the extension possibilities of the framework (which is paradoxical for a framework)
dunno if this applies here - just wanted to write it down :)

All other descriptor classes were always made internal and it simplifies maintenance. I don't think we ever had requests to open these since they exist. Regarding the OptionsResolverWrapper, I don't see use-cases in userland (and would probably not belong to the form component if the use case was legit).

instead of removing it here, the definition should be part of the file loaded only when the config is enabled, inside registerFormConfiguration.

@stof I'm no sure :/ as It was the modus operandi and the consensus for other commands #23624, #23801, #23694 (comment)

Regarding the OptionsResolverWrapper, I don't see use-cases in userland (and would probably not belong to the form component if the use case was legit).

@ogizanagi should I move the OptionsResolverWrapper class to OptionsResolver Component?

@yceruto I would let it as is. If one asks for extensibility with a legit use case, we can move it easily, removing the internal flag.

Same opinion as @chalasr

Thanks @yceruto.

@yceruto Tests are failing on master, could you have a look? https://travis-ci.org/symfony/symfony/jobs/270338064

Sure, I'll take a look soon.

Done in #24059

Thanks @ogizanagi! I'm really busy right now.