Add prefer-class-fields rule

[FRSgit]

Adds prefer-class-fields rule which turns:

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

into:

class Foo {
  foo = 'foo';
}

Fixes #314

---

IssueHunt Summary

Referenced issues

This pull request has been submitted to:

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

---

[fisker]

The operator didn't checked

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

[FRSgit]

You're right, it should be ignored. Fixed here: 21e3cf1

[fisker]

The left property didn't checked

			class Foo {
				constructor() {
					this[foo.bar] = 'foo';
				}
			}

[FRSgit]

I think in this case we should ignore any kind of reporting - foo.bar might be dynamic and checking if it is or not is a rabbit hole with potentially lots of nested jumps.

I can handle cases like this['foo'] = 'foo'; though

[FRSgit]

Added a valid test case to cover the dynamic case: 633829c

[FRSgit]

And here: 0e6afb3 added support for simple strings & template strings.

I ended up removing the support for strings/template strings. With support for multiple "name formats" the whole process looks like this:

1. check whether string is actually translatable into other "name formats",
2. iterate through all of the formats and remove class fields that are already there: foo='foo', ['foo']='foo', etc.
3. move field declaration from constructor to the class itself: foo='foo'

Supporting those IMO brings lots of unespected edge cases in the points 1 & 2. It's hard to predict which string and how can be represented. Simple this.foo can be written as this['foo'], this["foo"] or this[`foo`], but string with kebab-case like: "foo-something" can be only used as this['foo-something'], this["foo-something"] or this[`foo-something`]. For every of those "name formats" there are other characters that are restricted (and I don't want even start about the escaped characters 😄 ).
It's just too much of a hassle and places that can potentially break

[fisker]

I didn't mean to ask support for strings, please test

			class Foo {
				constructor() {
					this[foo] = 'foo';
				}
			}

[FRSgit]

Don't worry, I didn't understood it well then :)
Done: f9caf1b

[fisker]

What should we do if the assignment is unreachable?

			class Foo {
				constructor(x) {
					if (x) {return}
					this.foo = 'foo';
				}
			}

[fisker]

The fix also changes code if the property already exists.

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

[FRSgit]

True. IMO in this case the output should be:

class Foo {
    foo = 'foo';
    constructor() {
    }
}

[FRSgit]

done: a7edb37

[sindresorhus]

tab-indentation

[FRSgit]

378f58b

[fregante]

What should we do if the assignment is unreachable?

It's dynamically set, so it cannot be statically defined. It should not be reported by this rule.

[FRSgit]

Hey @fregante!
Thanks for your input about the linting - is there a ruleset somewhere which I could use? The lint task in this repo is not doing this much (at least for me) and it removes some of your changes 😄 E.g. it seems that the part /** @type {import('eslint').Rule.RuleModule} */ is required by the lint task - after your change it was failing with:

So, I've reverted this one change.

Or maybe we can just agree that once the work in this PR is done you'll maybe just run your linter on it once?

[FRSgit]

Handled stopping of the static analysis on unsupported case: 3376845