Update: add fixer for no-unused-labels

[not-an-aardvark]

What is the purpose of this pull request? (put an "X" next to item)

[x] Add autofixing to a rule

What changes did you make? (Give an overview)

This adds a fixer for no-unused-labels.

foo: while (true) {}

// gets fixed to:

while (true) {}

Is there anything you'd like reviewers to focus on?

Nothing in particular.

[mention-bot]

@not-an-aardvark, thanks for your PR! By analyzing the history of the files in this pull request, we identified @vitorbal, @mysticatea and @BYK to be potential reviewers.

[eslintbot]

LGTM

[platinumazure]

Hmm. I'm slightly uncomfortable about adding a fixer here in case the label is only "unused" due to a typo in a named break/continue statement.

@not-an-aardvark Any thoughts?

[not-an-aardvark]

I'm not too concerned about this, because using an undeclared label in break/continue will result in a syntax error. For example, the following is invalid syntax:

foobar: while (true) {
  break fooabr; // oops, this was a typo
}

[mysticatea]

I have a concern, some editors have the feature it executes --fix on save files. If someone which has the habit of saving files frequently, they might lose labels from unfinished code on save.

[vitorbal]

I have a concern, some editors have the feature it executes --fix on save files. If someone which has the habit of saving files frequently, they might lose labels from unfinished code on save.

Hmm, that can indeed be quite annoying...

[platinumazure]

I'm worried about the editor integrations as well.

[not-an-aardvark]

Personally, I don't think we should worry about editor integrations too much -- we already have a lot of fixers that could get in the way if they are applied while the user is writing the code. For example:

/* eslint curly: ["error", "multi"] */

if (foo) {
  bar();

  // ... planning to put more statements here
}

If I'm in the middle of filling in the if statement, I want to keep the curly braces, because I plan to put more lines in the block. However, if I autofix on save, ESLint will remove the block.

Another example:

/* eslint no-useless-return: error */

function foo() {
  if (bar) {
    return;
  }

  // ...planning to put more statements here
}

If the code is autofixed on save before the statements after the if statement are added, the return statement will be removed.

---

In general, rules will often "incorrectly" report things when the code that they're acting on is partially unwritten. By enabling autofix-on-save, I think users are opting into this behavior.

[not-an-aardvark]

TSC Summary: This PR proposes adding a fixer for no-unused-labels. The fix is safe and works well with other rules such as no-extra-label, but a few people have expressed concern that the fixer will get in the way if it's run on unfinished code, e.g. in an editor integration.

TSC Question: Should we add a fixer for this rule?

[mysticatea]

Related: #7955

We already have several rules which might modify unfinished codes unintentionally; curly, no-extra-parens, no-extra-bind, no-useless-return, no-lonely-if, no-trailing-spaces, prefer-arrow-callback, prefer-const, ...

I agreed that people should opt-out those rules when they use autofix on save.

[kaicataldo]

As per the TSC discussion, this is now accepted.

[mysticatea]

As always, I think we should consider comments.

A: // some comments...
while (a) {
    // do something.
}

[eslintbot]

LGTM

[mysticatea]

LGTM, thank you!