Potential bug when formatting fails

[Christian Alfoni]

Hi there and thanks for a great package! We are using this to drive our linting at https://projects.codesandbox.io/. 😍

One thing I have noticed implementing this is that when we combine eslint with prettier and run formatting with:

["--stdin", "--fix-to-stdout", "--stdin-filename", filepath]

We always get back the contents we sent. In other words we can not identify when the formatting has an error.

With prettierd we do get an error response (Final line is "# exit 1") when the formatting fails. I see comments in code about "no output" when no fixing has occured, but that seems to default to the input again? For reference:

    // No output will be returned if there are no fixes
    callback(null, (report.results[0] && report.results[0].output) || text); <= When no output, it sends the text

On this note, I am curious. When the TCP response is the actual code that was formatted, how can we safely identify it as an error? In theory someone could actually have # exit 1 as their final line in the code... unlikely... but could happen.

Thanks again 😄

UPDATED:
I did a bit more research on eslint and it does not really give explicit formatting errors, as it is really just a lint. But I was thinking if there are fatalErrors this response callback could be called with an error instead. Anyways, just some thoughts.

[Maximilian Antoni]

I'm not sure I understand what the question is. The --fix-to-stdout option must return the fixed up input, or the original input in case of an error. Otherwise editors would replace the highlighted text with the error message, which isn't very helpful.

[Christian Alfoni]

Yeah, I guess I am just curious why VSCode LSP supports formatting errors, when it does not seem like any formatters are able to give an error when the formatting fails, as it just return the input like you say 🤔

So the way prettierd works is that a formatting error will result in the stdout to be the error message of the formatting with the # exit 1 as the final newline, indicating an error (Coming from the fail response utility in core_d). This allows us to create an error LSP messages back to the client. So the client in this case does not replace the text, it rather handles the error.

But I guess this is exactly where the needs differs. We are mapping formatting to an LSP response, which does allow for an error... but normally you would talk directly to the formatter where it is expected that any returned result is what to be replaced in the text editor 🤔

The ultimate goal here was really to improve UX by notifying the user when the formatting fails, but this was definitely a "nice to have" on our end. We can solve this in other ways no matter, like looking at any critical ESLint diagnostics, preventing formatting etc.

Thanks for the response @mantoni! ❤️