Make CLI more empathic to the user

[rishabh3112]

Is your feature request related to a problem? Please describe.
Currently CLI gives error or gives whole help in case of invalid interaction with the CLI.
I propose to make the CLI respond to errors and invalid flags with prompts to help user to get their work done instead of forcing user to study errors and correct their command to CLI.

Describe the solution you'd like
I would like user to answer prompts in case of invalid value of a flag or invalid flag altogether to let user complete it's task.

I have started working on this with #1255 which is aimed for invalid flags.
For further work on this issue we need to validate the value of args passed by user before passing their value to the webpack complier so as to avoid errors.

Describe alternatives you've considered
Alternatives are already in place, i.e. printing full help and showing just errors.

Additional context
https://github.com/lirantal/nodejs-cli-apps-best-practices/blob/master/README.md#12-build-empathic-clis

[aquibbaig]

Hi @rishabh3112. Any progress on this yet? I'd like to pick this issue up.

[rishabh3112]

Hi, I am currently working on polishing the handling of the invalid flag case.

[aquibbaig]

@rishabh3112 Cool.

[aman29271]

I really like this git features, when user gives some invalid command then it shows the list of possible commands that the user may want to use.
For example :

~/Desktop/webpack-cli$ git statu
git: 'statu' is not a git command. See 'git --help'.

The most similar commands are
        status
        stage
        stash

It really helps users understanding the CLI in easy way. This could be one of the way to handle invalid commands and flags.

[snitin315]

@rishabh3112 I read the docs above and found that now we have covered major of the things in recent months like -

1. colorful CLI.
2. Zero configuration.
3. Appropriate and informational errors and warnings are in place.
4. Better error handling in case of invalid args.
5. compatibility with webpack 4 and webpack 5.
6. compatible with different versions of Node.js and different platforms (Windows, macOS, Linux )
7. proper use of exit codes.
8. better integration with the webpack ecosystem.
9. more tests.

anything else you want to specify?

[rishabh3112]

There is definitely an improvement but there are couple of this still left to be addressed:

• We need to give users information how to resolve a particular error. Like, when we throw Errors, we should also provide remedial information on how can we recover from this error.
• We need to be more state full, like we can provide status of project, based on previous executions and current configurations (like what git status does), which would help user to get more out of webpack.

In nutshell, aim of this issue is to make CLI better at helping user and not just being better doing work for the user (which it (almost) already is).

[alexander-akait]

We need to give users information how to resolve a particular error. Like, when we throw Errors, we should also provide remedial information on how can we recover from this error.

We validate configuration, so https://github.com/webpack/schema-utils respect for this, for other internal errors we already have good messages, maybe we can improve it in future, but not I don't see problems

We need to be more state full, like we can provide status of project, based on previous executions and current configurations (like what git status does), which would help user to get more out of webpack.

Can you clarify?

[rishabh3112]

We validate configuration, so https://github.com/webpack/schema-utils respect for this, for other internal errors we already have good messages, maybe we can improve it in future, but not I don't see problems

Errors are pretty "informative" in my opinion as well. But if we provide errors with a lot of webpack related jargons to a complete novice, they would never know what would be "next step" for resolving that error. It contributes to increase in learning curve required to use webpack.

We need to be more state full, like we can provide status of project, based on previous executions and current configurations (like what git status does), which would help user to get more out of webpack.

Like in git status, we can get information like which files are changed, Are we in middle of a rebase/merge, etc. We can also provide information like what is current bundle size we are getting, errors we encountered, etc (based on previous invocations) and is current configuration valid (based on current configuration), etc.

This issue is pretty open ended but we should at least reach a baseline where new users are able to get working on a project w/o going through a big learning curve to actually learn how to use it and resolve problems they face in between quickly.

[alexander-akait]

Errors are pretty "informative" in my opinion as well. But if we provide errors with a lot of webpack related jargons to a complete novice, they would never know what would be "next step" for resolving that error. It contributes to increase in learning curve required to use webpack.

Can you provide example? I think it is out of scope webpack-cli, because only webpack known what option is mean and how it can be fixed. I think related https://github.com/webpack/webpack/projects/7

Like in git status, we can get information like which files are changed, Are we in middle of a rebase/merge, etc. We can also provide information like what is current bundle size we are getting, errors we encountered, etc (based on previous invocations) and is current configuration valid (based on current configuration), etc.

This issue is pretty open ended but we should at least reach a baseline where new users are able to get working on a project w/o going through a big learning curve to actually learn how to use it and resolve problems they face in between quickly.

It should be in stats.toString(), it is real is not our scope

[snitin315]

Yes, these hints for errors should be provided by the webpack. CLI can just log them.

[alexander-akait]

Need focus on this after refactoring

[alexander-akait]

I think we done #1261 (comment), I think ask developers on invalid flags is not good idea, because most of developers use scripts and other runners, so it requires fix command/option in these files, it will be hard to implement (impossible)

If somebody want to more colors - PR welcome