Im not sure about the fix. AFAIK the root-cause is a bit deeper, as we wrongly merge the application- and command definitions at some point.

It doesnt solve e.g. #17804

The last time i took a stab it i ended up with #20054. If i remember well it solved the synopsis as well.

Should target 3.4 now. Or maybe master btw if this is considered as an improvement.

@nicolas-grekas rebased on 3.4. thanks.

@ro0NL I think it is normal that this PR doesn't fix #17804. I don't reproduce this bug on Symfony commands. Maybe this bug was existing before in Symfony codebase but it seems to not be the case anymore (or perhaps with a specific behavior ?). I'm ok that this bug still exists in composer, but composer override widely the Application class. IMO it's a composer bug.

I read #20054, my PR has not the ambition to rethink the arguments merging between Application and Command. Its goal is more straightforward. In getSynopsis method, the task name is hardcoded. So I remove the task name placeholder from the displayed arguments. It's nothing more.

In getSynopsis method, the task name is hardcoded. So I remove the task name placeholder from the displayed arguments

but having this unexpected argument in the command definition smells already, right now we're kinda ducktaping it.

$ bin/console help   
Description:
  Displays help for a command

Usage:
  help [options] [--] <command> [<command_name>]

Arguments:
  command               The command to execute           <==== THIS =====<
  command_name          The command name [default: "help"]

I think the issue is still there (4.2) :)

@ro0NL thanks for your clarifications, I was wrong, so it's not a composer bug.

Status: Needs Work

If you like we can re-try #20054 on master. That time i was pretty convinced about it :)

@ro0NL I'm not sure to understand why you closed it ?

no feedback :) felt like nobody dares to touch it / get involved :P

@ro0NL

If you like we can re-try #20054 on master. That time i was pretty convinced about it :)

Yes please, I tested it on 3.4, it works fine and the approach looks good to me :)

Closed in favor of #20054