Show `--no-devtool` tip for `--devtool false`

[chenxsan]

Is your feature request related to a problem? Please describe.

So it's my first time using the --devtool from the command line, I just want to disable it with a false value which is valid according to webpack's schema, so I just pass a false to --devtool:

npx webpack --mode development --devtool false

Now I got this error:

webpack-cli] Invalid configuration object. Webpack has been initialized using a configuration object that does not match the API schema.
 - configuration.devtool should match pattern "^(inline-|hidden-|eval-)?(nosources-)?(cheap-(module-)?)?source-map$".
   BREAKING CHANGE since webpack 5: The devtool option is more strict.
   Please strictly follow the order of the keywords in the pattern.

Which is sort of misleading since devtool option can accept a false value. The problem here is the cli translates --devtool false into {devtool: 'false'}. The string 'false' is not valid value for the devtool option.

After some researches, I've figure out to use --no-devtool instead of --devtool false.

Describe the solution you'd like

Is it possible to show a tip to users when they're trying to set a false value for option like what I did above? It would be helpful in my opinion.

E.g.:

npx webpack --mode development --devtool false
[webpack-cli] Seems you want to disable the `devtool` option in a form that webpack-cli doesn't support, please use `--no-devtool` instead.

Same can be applied to other --no-xx arguments.

Describe alternatives you've considered

Additional context

[alexander-akait]

Make sense to output this for all boolean values when false is provided

[chenxsan]

I'm closing this feature request now as it's much complex than I expected.

Generally I think we can coerce 'false' to false for use cases like --devtool false, e.g.,

However, if we are going to accept a pattern like --devtool false, then --amd false or --bail false should work as well to keep consistency, which means they should accept the String type since that false passed in cli arguments is actually a String type, and that would require drastic refactors as far as I can see, it might not worth it.

[snitin315]

Let's keep it open in case someone wants to tackle it in the future. Also, I think for now we can show the tip alongside the error.

[alexander-akait]

To be honesty I think it is standard for CLI using --foo and --no-foo for true/false values, yes --foo false is string, so I think it can be closed, better to docs if somebody has problems with understanding, let's close