Add option to semi to require semi colons after arrow function definitions in class body.

What rule do you want to change? semi / no-extra-semi

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

How will the change be implemented? (New option, new default behavior, etc.)? Please add the option to require use of semi colons after class arrow function definitions in semi or require no semi colon in no-extra-semi.

The main thing is that either way, there is no ESLint rule that produces consistency in the code wrt to semi colons after class arrow functions. Here is the ECMAS definition for class body. I can make sense of this either way wrt arrow functions in the class body. http://www.ecma-international.org/ecma-262/11.0/index.html#prod-ClassBody

Please provide some example code that this change will affect:

class Project extends React.Component {

    constructor() {
    } // Require no semi colon in no-extra-semi (current)

    lifeCycle() {
    } // Require no semi colon in no-extra-semi (current)

    withoutSemi() {
    }  // Require no semi colon in no-extra-semi (current)

    withSemiArrow = () => {
    }; // Optional require semi colon in semi (requested)

    withoutSemiArrow = () => {
    } // Optional require semi colon in no-extra-semi (requested)

} // Require no semi colon in no-extra-semi (current)

What does the rule currently do for this code? semi add semi colons in many place. no-extra-semi removes them in many places.

Are you willing to submit a pull request to implement this change? Im not sure I would have the knowledge how.

[sirmspencer]

@sirmspencer thanks for the issue!

All core rules will be updated to support this syntax when class fields proposal reaches stage 4, per our policy about experimental features.

In the meantime you can use @babel/semi rule from @babel/eslint-plugin, instead of the core semi rule.

Thank you so much. The @babel/eslint-plugin works great for what I need.

[eslint-deprecated[bot]]

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 reach accepted status after 21 days tend to never be accepted, 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.

Thanks for contributing to ESLint and we appreciate your understanding.