Compare computed keys by tokens in no-dupe-keys

[mdjermanovic]

What rule do you want to change?

no-dupe-keys

Does this change cause the rule to produce more or fewer warnings?

More

How will the change be implemented? (New option, new default behavior, etc.)?

I'm not sure, it could be new default behavior.

Please provide some example code that this change will affect:

/* eslint no-dupe-keys:error */

var foo = {
  [a]: 1,
  [a]: 2
}

What does the rule currently do for this code?

No warnings.

What will the rule do after it's changed?

Warn about the duplicate key.

Are you willing to submit a pull request to implement this change?

Yes, I'll be glad to do it.

[platinumazure]

What should happen in this situation, where the keys have side effects?

/* eslint no-dupe-keys:error */

var foo = {
  [a++]: 1,
  [a++]: 2,

  [b()]: 3,
  [b()]: 4
}

[mdjermanovic]

That would be bad. Maybe to compare just identifiers, I guess that's the most common use case.

Albeit, in theory there could be something like this:

var foo = {
  [a]: a++,
  [a]: 2,
}

[kaicataldo]

I know my comment kicked off this discussion, but given the discussion above, I agree that this doesn't seem like a case we can enforce reliably and safely. I think the current behavior probably makes the most sense. @mdjermanovic Thanks for exploring this!

[dwelle]

IMO this is a useful feature to implement, even if for the simple case of:

var foo = {
  [a]: 1,
  [a]: 2,
}

where the key isn't an expression (as @platinumazure noted) other than a simple variable reference.

In our team, we've already had at least one painful debugging experience due to this.

If the worry is that doing e.g. { [o.id]: "a", [o.id]: "b" } could result in false positive in case o.id was a self-incrementing getter (how common is that?), then we can add a rule exception for computed keys if one desires, or don't lint for nested computed keys.

Or is there something else I'm not seeing here?

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