Support braces for no-fallthrough

[cowwoc]

What version of ESLint are you using?
3.0.1
What rule do you want to change?
no-fallthrough
What code should be flagged as correct with this change?

/*eslint no-fallback: ["error", { "commentPattern": "[\\w\\s]*fallthrough" }]*/
var foo = ...;
switch(bar) {
    case 0: {
      if (typeof(foo) == 'string')
        return doSomething();
      // Otherwise, fallthrough
    }
    default:
      doSomethingElse();
}

What happens when the rule is applied to this code now?
Errors:
Expected a 'break' statement before 'default'.

... Basically I am asking for the rule to support case statements that contain braces.

[platinumazure]

Seems reasonable to me.

Just to make sure I understand your proposal, using ESTree terms:

1. For a given SwitchCase,
2. If its consequent contains one statement and that is a BlockStatement,
3. Then the rule logic should effectively be run on the BlockStatement instead of the SwitchCase, and a // falls through label or similar at the end of the BlockStatement should be acceptable and not cause a warning.

Does that sound correct? (Note: I'm basing this on the AST seen here.)

[cowwoc]

@platinumazure Yes, that sounds about right :) Thank you.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get enough support from the team and so I'm closing it. 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 consensus after a long time tend to never do it, and as such, we close those issues. This doesn't mean the idea isn't interesting, just that it's not something the team can commit to.

[cowwoc]

@not-an-aardvark I didn't get the feeling that there was a lack of consensus over this issue. Please see the last 2 comments.

[ilyavolodin]

@cowwoc what @not-an-aardvark means is consensus from the team. Every proposed change has to be supported by 3 team members and championed by one. Unfortunately, in this case, none of the team members elected to support this change other then @platinumazure
As @not-an-aardvark message mentions, we found that if the issue doesn't gain support shortly after being created, it's most likely will be forgotten and will never gain support required for implementation:-( That's why we periodically close older issues.

[cowwoc]

Fair enough. Thanks for the clarification. Hopefully this will be revisited in the future.

[j-f1]

This has been brought up again in #9080.