prettier-eslint-cli: Allow prettier-eslint-cli to write eslint errors/warnings to stderr?

Great. With the holidays not sure exactly when I will be able to finish the PR, but I will try to get it done by mid-next month if not before.

But eslint has no behavior analogous to prettier-eslint-cli --report-issues without the --write option,

I don’t quite follow, isn’t eslint command without --fix itself the similar thing?

No, eslint without --fix simply tells you about all questionable formatting in your code, it does not (even attempt to suggest how to) correct your code. On the other hand, prettier-eslint-cli --report-issues without the --write option would still write out the corrected code to stdout, just the idea is that it will now also tell you about the issues that it does not now how to fix (without --report-issues those issues are silenetly ignored). So the question is where should that additional information go?

What means I want when --write is not specified but --report-issues is, I want to follow the behavior of eslint command without --fix.

But as mentioned above, eslint without --fix does not provide corrections, whereas prettier-eslint-cli does always produce corrections. The closest eslint variant to what prettier-eslint-cli does is eslint --fix-dry-run – but that does not write out the corrected code. Invoked exactly like that, all it does is write to stdout the unfixable errors, amusingly enough. There is another variant eslint --fix-dry-run --format json which writes a big JSON structure to stdout that encodes all of the errors (fixable and unfixable) as well as the proposed fixed code (in one of the top-level properties of the structure). But I don’t think suddenly adding a JSON output format to prettier-eslint-cli makes sense. It is focused on correcting code; I would just like to know in addition if it noticed any unfixable problems with the code. This is not really a mode of operation of eslint, and would if implemented be a noticeable added value of prettier-eslint-cli if we can agree on an implementation. Hence, to reiterate my working proposal:

1. In the prettier-eslint-cli --write --report-errors case, which is quite analogous to eslint --fix, you would like to match eslint behavor and send the errors/warnings to stdout.

2. In the prettier-eslint-cli --report-errors case, to match the current behavior of prettier-eslint-cli, the corrected code should be written to stdout. There isn’t a closely analogous mode of eslint, and so to make it easy for people using the tool to separate the suggested fixed code from the (unfixable) warnings/errors, I propose the latter be sent to stderr in this case. Such behavior doesn’t really conflict with eslint, and will make it quite easy to use the tool to do whatever you want with both the fixed code and with the warning/error information – just send stdout and stderr (respectively) wherever you like.

Please let me know if this scheme meets with your approval for a PR, or suggest concrete different behavior that you would like to see implemented. Thanks!

I like --report-issues. But I am unclear: is it possible to support both --report-issues and --report-issues error? How can the command-line parser then tell whether error is the argument to --report-issues or a glob argument? Or should there be a mandatory argument so that you must say either --report-issues all or --report-issues error (or --report-issues none which is the current behavior and so presumably the new default)?

As far as where the errors/warnings go, since the default behavior of prettier-eslint is to write the formatted version to stdout, it seems to me this information has to (all) go to stderr. It’s also convenient because my editor is expecting nothing on stderr and if there is anything, it shows it in a popup. But if you have another convention in mind for what should go to stdout/stderr under what conditions, just let me know.

When these design points are settled I will be happy to supply a PR as soon as I am able.