no-fallthrough: Don’t warn when falling through case statements with no bodies

Tell us about your environment

• ESLint Version: v4.4.0
• Node Version: v7.9.0
• npm Version: 5.3.0

The broken code

switch (file.status) {
  case AppFileStatus.New:
    return formatPatchHeader(null, file.path)

  case AppFileStatus.Conflicted:
  // One might initially believe that renamed files should diff
  // against their old path. This is, after all, how git diff
  // does it right after a rename. But if we're creating a patch
  // to be applied along with a rename we must target the renamed
  // file.
  case AppFileStatus.Renamed: // *** Expected a 'break' statement before 'case'  no-fallthrough
  case AppFileStatus.Deleted:
  case AppFileStatus.Modified:
  case AppFileStatus.Copied:
    return formatPatchHeader(file.path, file.path)
}

This appears to be because of the comments between AppFileStatus.Conflicted and AppFileStatus.Renamed. If I remove the comments, it works as intended.

Minimal repro:

switch (1) {
  case 1:
  // comment
  case 2:
    break
}

[j-f1]

Can this become a request to add an option to only report when there’s actually code in the case @not-an-aardvark?

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.