Request range formatter for ESLint

[Tsimopak]

The version of ESLint you are using.
7.13.0

The problem you want to solve.

I made an issue on vscode that I can't reformat selected range:
microsoft/vscode#108808

And they answered that ESLint doesn't provide an API to do so, so I request to make one since it can be very useful.

[mdjermanovic]

Hi @Tsimopak, thanks for the issue!

Can you please provide more details on what exactly should be implemented in ESLint?

ESLint provides a list of all fixes for the given source code, and integrations can already filter that list to get only those in the selected range.

[Tsimopak]

Hi @Tsimopak, thanks for the issue!

Can you please provide more details on what exactly should be implemented in ESLint?

ESLint provides a list of all fixes for the given source code, and integrations can already filter that list to get only those in the selected range.

I Honestly not sure what should be implemented, but it's not possible at the moment to format selected range in Visual Studio Code, at first I thought it's a bug, but when I asked at VSCode's repository they said it's not available since there isn't an API.

According to @dbaeumer from this link: microsoft/vscode#108808

No, ESLint doesn't contribute a range formatter since they have no API to do this.

[dbaeumer]

Just to clarify: me filtering the fixes will IMO be problematic if a fix one depends on a fix two and I only include one of them. This has the potential of breaking code. IMO to make that work correctly ESLint would need to offer API that ensures that the fixes reported for a range don't cause any problems to the source code.

[mdjermanovic]

@dbaeumer thanks for clarifying!

if a fix one depends on a fix two and I only include one of them

Rules shouldn't produce such fixes. For example, no-extra-parens makes a single fix to replace (foo) with foo, not two fixes.

However, it's true that there are some plugins where fixes depend on each other in the actual version (prettier/eslint-plugin-prettier#65).

We could maybe add an API to check if a single fix or a list of fixes produces parsing error, but that would affect performance and it seems better to fix problematic rules instead.

[nzakas]

I think we are bumping up against a limitation of how ESLint handles fixes here. ESLint was never intended to be used for intricate source code formatting, and that just kind of happened while no one was looking. I don't think it makes sense to make any changes for this at this point.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.