Add semi option to strengthen beforeStatementContinuationChars

What rule do you want to change?

semi

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

More.

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

New option that disables the exception for { "beforeStatementContinuationChars": "never" } that currently allows semicolons before statement continuation characters. Currently “never” implements behavior that I’d describe as “never, if it doesn’t make ASI hazard”, whereas I’d really like to use “never” in general.

Maybe something like “allow ASI hazard” or something? The default might be { "allowAsiHazard": true } and the behavior I’m looking for would be { "allowAsiHazard": false } or similar. I’m very open to suggestions on how to best implement this.

Please provide some example code that this change will affect:

/*eslint semi: ["error", "never", { "beforeStatementContinuationChars": "never"}] */

console.log(42)
;(function() {
    // ...
})()

What does the rule currently do for this code?

No errors detected.

What will the rule do after it’s changed?

Detect the error caused by the semicolon before the statement continuation characters.

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

Yes.

---

Backlink: https://github.com/standard/standard/issues/1402

[platinumazure]

I really don’t see why semi couldn’t be enhanced for this case.

Part of my difficulty with this is, I see semi as a rule primarily about semicolon tokens, but it seems @mysticatea (and maybe others) see this as a rule about the end of statements. So, because I see this as a rule about semicolon tokens, the current behavior of "beforeStatementContinuationChars": "never" is utterly incomprehensible to me. I don’t see any value in distinguishing between whether the semicolon is part of the previous statement (i.e., is necessary for ASI) vs if the semicolon represents an empty statement, for the purposes of the semi rule. I can’t imagine many of our users would be keeping track at that level of detail.

I would much rather add a new option value to semi’s "beforeStatementContinuationChars" and have “never” actually mean never– no semicolons allowed at that location. If we need to add a new option representing the current behavior (no semicolons allowed, but only if the semicolon is unnecessary for ASI purposes), I would much rather do that in this rule (e.g., "beforeStatementContinuationChars": "warnIfUnnecessarySemi" or similar). If all of this needs to be done in 7.0.0 due to breaking changes, of course I would be okay with that.

[mysticatea]

As I said in https://github.com/eslint/eslint/issues/12228#issuecomment-528652769, I prefer a new rule. It would be no-workaround-semi or something like.