Support for different keyword-spacing with optional catch binding syntax

What rule do you want to change?

keyword-spacing

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

Fewer, depending on other configuration (Never more)

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

Probably new option

Please provide some example code that this change will affect:

try {
	foo();
} catch(ex) {
	return console.error(ex);
}

// https://tc39.es/proposal-optional-catch-binding/
try {
	foo();
} catch { // This is the root issue
	return console.error("Failed");
}

What does the rule currently do for this code?

With "catch": {"after": false} the first example is, as expected, correct, however when ignoring the thrown error like in the bottom example it still expects you to not have a space after the catch thus causing obviously ugly code.

What will the rule do after it’s changed?

My idea is to add a seperate rule, something like catchNoBody which defaults to whatever catch is set to but allows you to have a different keyword-spacing for catch clauses like the second one

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

I probably would not know how to properly implement this seeing the need for inheritance so no.

[mdjermanovic]

I reopened this thinking it was a bug, but now it looks more like an enhancement to me.

keyword-spacing controls spaces between catch and (, catch and {.

space-before-blocks controls spaces between ) and {, so keyword-spacing shouldn’t enforce anything there.

With the actual schema, I think it’s impossible for keyword-spacing to know that user wants catch(e), but at the same time catch { instead of catch{, so this would most likely need a new option.

(this is somewhat similar to the else++foo issue, a difference is that this one doesn’t seem to be an edge case)

[anikethsaha]

I think this should be re-open! cause it is bug and it will be agreed by the new policy as well