More documentation on conflicting fixes

[RunDevelopment]

The developer documentation about rules (docs/developer-guide/working-with-rules.md) doesn't contain enough information about rules. This is a followup to eslint/archive-website#791.

The following questions should be answered:

1. Q: When do fixes conflict?
   A: "Conflicting fixes are fixes that would be applied to the same part of a string. So if two fixes want to modify characters 0 through 5, only one will be applied."
2. Q: If fixes conflict which one will be applied?
   A: Fixes are not guaranteed to be applied. ESLint may choose to apply or not to apply any fix.
3. Q: Can the (rule) developer affect which one of the conflicting fixes is applied?
   A: No.

Are you willing to submit a pull request to implement this change?
No. I'm not good at writing technical documentation.

[mdjermanovic]

Thanks for the issue!

I think 1. and 3. would be very useful, but not sure if we should document 2.

• Q: When do fixes conflict?
  A: "Conflicting fixes are fixes that would be applied to the same part of a string. So if two fixes want to modify characters 0 through 5, only one will be applied."

I agree that we should specify this. It's an important detail for cases like #13706 and the i flag example you described in eslint/archive-website#791 (comment).

• Q: If fixes conflict which one will be applied?
  A: Fixes are not guaranteed to be applied. ESLint may choose to apply or not to apply any fix.

Would appreciate more opinions on this. Specifying these details might disallow further optimizations, like the one we made in #8035. On the other hand, rule developers should be aware of how this works when writing tests with overlapping ranges.

• Q: Can the (rule) developer affect which one of the conflicting fixes is applied?
  A: No.

Make sense to document this.

[mdjermanovic]

Maybe I misunderstood the proposal for 2.. Does it include details on which of the conflicting fixes will be chosen?

[RunDevelopment]

Does it include details on which of the conflicting fixes will be chosen?

Yes. If two of my rules produce fixes that conflict, then I'd like to know which one is applied.

I know that right now it's going to be the left-most fix after being sorted by this function but that very specific implementation detail probably shouldn't make it into the public doc. Explicitly stating that it's undefined behaviour in that context should suffice.

[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.

[mdjermanovic]

Reopening, as it seems useful to clarify this in the docs.

[arminyahya]

About 2. can we add a few details about how it works?

@mdebruijne

[Gautam-Arora24]

Hi! Are we still interested to solve this issue?

[btmills]

The additional changes as currently described sound reasonable to me. Like others, I'd prefer to leave 2 as undefined behavior to avoid committing ourselves to a particular implementation.

[snitin315]

Marked as accepted since we have 3 👍🏻