Rule proposal: `prefer-class-fields` #314

Sounds good, but I think we should wait until ESLint supports class fields.

Should it also handle:

class Foo {
  constructor() {
    this._foo = 'foo';
  }
}

to

class Foo {
  #foo = 'foo';
}

?

I think a rule for private fields would be awesome, yeah. I don't think we can realistically auto-fix those, however, because people abuse _foo access too regularly and it would very quickly break code.

So you think private fields should be a separate rule?

I don't think we can realistically auto-fix those, however, because people abuse _foo access too regularly and it would very quickly break code.

👍

Yeah. As a general principle, I prefer rules to be have the smallest reasonable scope.

In this case, I can also see why a team might want to convert to class fields because of the fixer but not want to enable the private fields rule right away because they'd have to move a bunch of code around.

Issue for private class fields: https://github.com/sindresorhus/eslint-plugin-unicorn/issues/979

Does ESLint support class fields yet?

Does ESLint support class fields yet?

It does now

This rule would be pretty useful on Error constructors like:

class MyError extends Error {
  constructor(message: string) {
    super(message);
    this.name = "MyError";
  }
}

👇

class MyError extends Error {
  name = "MyError"
}

This is accepted.

bump

@fregante has funded $30.00 to this issue.

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

FYI I've implemented this rule here, feel free to review & comment!