The issue has been solved
There is a superior pattern for class field declarations that can declutter constructors (often making them totally unnecessary.) The feature is still considered experimental but it works out of the box with babel.
Fail:
class Foo {
constructor() {
this.foo = 'foo';
}
}
Pass:
class Foo {
foo = 'foo';
}
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.
posted by sindresorhus over 4 years ago 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"
}
posted by sindresorhus over 3 years ago 
posted by jimmywarting almost 2 years ago 
posted by issuehunt-oss[bot] over 1 year ago 
FYI I've implemented this rule here, feel free to review & comment!
posted by issuehunt-oss[bot] 2 months ago 
IssueHunt