In summary:

before 5.2, both --ansi and --no-ansi returned the same false default value.
Since we introduced the Negatable option, --no-ansi is always ! --ansi (true by default) which broke some applications that expect it to have a default false

Having 3 states for a negatable option make sense: for instance

• true: user asked to enable it
• false: user asked to disabled it
• null: let the application choose the best solution

How can we fix the --ansi option issue @symfony/mergers ?

1. do nothing

😐 We believe that --ansi should default to false and no-ansi to true
👎 Still a BC break since 5.3.0 (see comments in #41723)

2. switch default to --ansi = null

👍 the cleanest way to say choose the best for the user.
👎 But a BC break for app relying on false with strict comparison getOption('ansi') === false

3. switch default to --ansi = null BUT option returns false in such case.

This is the behavior of this PR, and I'm not sure to like it.

👍 Restore the behavior of 5.2 and fix the BC
👎 New BC for people that use null default since 5.3
👎 This brokes the case "let the application choose the best solution"

4. add new values for the Negatable default: Negatable::DEFAULT_TRUE_TRUE, Negatable::DEFAULT_TRUE_FALSE, Negatable::DEFAULT_FALSE_TRUE, Negatable::DEFAULT_FALSE_FALSE that let people configure their option with fine grain for both positive and negative case.

👍 Fix issue in 5.2
👎 Ugly interface and more complex

This brokes the case "let the application choose the best solution"

How so? Isn't not passing --ansi/--no-ansi to let the application decide the 5.2 behaviour? I was thinking within the context of $output->isDecorated()

My personal opinion: 6 months have past since this BC break, so is it really worth to still complicate the API to fix it? (imho, everything different than the current behavior is less expected)
This can be fixed by Thinker by checking === null when Symfony 5.3+ is used. It's unfortunate that this BC break has made it in a stable release, but I'm not sure there is anything to do about it now (except from maybe documenting this more clearly in the Console CHANGELOG)

This is yet another example of how everyone can improve Symfony (and indirectly many projects not related to Symfony but using it's components) by testing out pre-releases.

This can be fixed by Thinker by checking === null when Symfony 5.3+ is used

this is the option 2.

At the moment, they can not know if user choose --no-ansi or if symfony used the default value.

So, to make it clear, this is what I would expect (and IIRC, this is the current behavior?)

But apps should rely on getOption('ansi') only: true = users wants it, false = user doesn't want it, null = decide what's best.

The current 5.3 behaviour is as follows:

And in 5.2 and lower:

With this PR, the behaviour is the same as 5.2. Difference is getOptions()['ansi'] === null instead of false. Am I correct here @jderusse?

Yes, @kbond is right.

the current behavior of negatable option (when user did not enter a flag)

BUT --ansi is configured with default false

Switching to null could be the right thing to do, but might be a BC break...

with my PR, the behavior will be

That will fix the issue for ansi. But have 2 drawback for other people:

• BC break for people that rely on having null
• no easy way to check if users did not provide an option (in fack, if both foo and no-foo are identical it means the user did not choose one.. but that's ugly)

Switching to null could be the right thing to do, but might be a BC break...

So option 2, right? My preference goes to this, since the BC break looks pretty mitigated to me and the fact it seems both the cleanest and simplest way to have an "auto" mode where the app is in charge of choosing the solution.

Using the standard negatable behaviour (option 2) is my preference as well.

Generally, I think apps should use $output->isDecorated() instead of checking the ansi option directly.