Proposal: Enforce consistent linebreak style for semicolons
See original GitHub issuePlease describe what the rule should do:
Enforce consistent linebreak style for semicolons. Require that they be placed either at the end of a line or beginning of a line.
While in a project that use semicolons after every statement, there is little question that the semicolon belongs at the end of the line. However, in a project that uses semicolons only where needed, it’s helpful to enforce the placement of the occasional semicolon.
What category of rule is this? (place an “X” next to just one item)
[X] Enforces code style [ ] Warns about a potential error [ ] Suggests an alternate way of doing something [ ] Other (please specify:)
Provide 2-3 code examples that this rule will warn about:
With "after"
, this would be an error:
foo()
bar(); // A semicolon is required here for the next statement to be interpreted as intended.
[1, 2, 3].forEach(a => { console.log(a) })
baz()
This would be correct:
foo()
bar() // A semicolon is required here for the next statement to be interpreted as intended.
;[1, 2, 3].forEach(a => { console.log(a) })
baz()
With "before"
, this would be an error:
foo();
bar()
;[1, 2, 3].forEach(a => { console.log(a) });
baz();
This would be correct:
foo();
bar();
[1, 2, 3].forEach(a => { console.log(a) });
baz();
Why should this rule be included in ESLint (instead of a plugin)?
Semicolon style is applicable to most projects that define a style guide. It varies significantly from project to project. Some using semis everywhere; others only where they’re needed. Developers new to no-semicolon projects may misplace the required semicolon. Developers on semicolon projects may prefer to enforce consistency as well.
This rule relates to semi
, but does not depend on, conflict with, or overlap with it, or any other rule.
The rule is straightforward to understand. It’s just like operator-linebreak
.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:4
- Comments:15 (15 by maintainers)
Top GitHub Comments
This has now been accepted!
@paulmelnikow It does as a statement, but as a rule, we have no precedence for such tightly coupled rules. I’m still not convinced that it would be a good idea to go down this route.