Rule "no-fallthrough" falsely triggers when using curly brackets

[danielhickman]

What version are you using?
v4.9.0

What did you do?

Config:

{
    "env": {
        "es6": true,
        "node": true
    },
    "extends": "eslint:recommended",
    "parserOptions": {
        "sourceType": "module"
    },
    "rules": {
        "no-fallthrough": [
            "error",
            {
                "commentPattern": "falls?\\s?through|break"
            }
        ]
    }
}

Code:

const item = "Test string";
switch (typeof item) {
	case "string": {
		// Run as if it was a number (below)
		// fallthrough
	}
	case "number": {
		console.log(item);
		break;
	}
}

What happened?

Console (worked as intended):

Test string

ESLint:

Expected a 'break' statement before 'case'. (no-fallthrough)

What did you expect to happen?

The same as without curly brackets, right? Removing the first or all of the case brackets prevents ESLint from erroring out the no-fallthrough message.

Code:

const item = "Test string";
switch (typeof item) {
	case "string":
		// Run as if it was a number (below)
		// fallthrough
	case "number": 
		console.log(item);
		break;
}

The empty block looks good for consistency especially since I want to comment something and not "stack" the case statements on top of each other.

[nzakas]

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 be implemented after 90 days tend to never be implemented, 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.