@bradzacher so change this test case to:

export class A {
  private readonly foo: string;

  constructor(foo: string) {
    this.foo = foo;
  }
}

I would have both.

private readonly foo: string = 'bar'; should be an invalid case for the config options: ['getters'], and it should be fixed appropriately.

As mentioned; the case with the assignment in the constructor should still be invalid, but there should be no auto-fix for it (use output: null to test this).

@JoshuaKGoldberg read the documentation you suggested. Do you think I'm getting warmer on having a solution that solves the actual bug?

I realize this code can be much cleaner, but wanted to just know if I'm going in the right direction.

Ok cool @JBhagat841 and I discussed this a bit; summarizing the key takeaways I had:

• Rule walkers do a single linear traversal through the node tree, so these :exits don't quote match up with the expected behavior.
• The strategy going forward will be to:
  1. Collect class properties that might need to be warned or errored on as they are found
  2. Inside the class constructor, mark any property assignments as warnings for those class properties
  3. Upon exiting the class constructor, mark any remaining property assignments as errors
• As with prefer-readonly, you might have to use parser services and will almost certainly need a stack of classes to make sure you're applying node warnings to the right class

That last point is where the trickiness comes in. Please enjoy these very convoluted edge cases 😄

const keyName1 = 'wat1'
const keyName2 = 'wat2'

class Parent {
  private readonly wat1 = true;
  private readonly wat2 = true;

  constructor() {
    this['wat1'] = true;
    this[keyName1] = true;
    this.wat1 = true;

    class Child {
      private readonly wat1 = true;

      constructor() {
        this['wat1'] = true;
        this[keyName1] = true;

        console.log(class GrandChild extends Child {
          private readonly wat2 = true;

          constructor() {
            super();
            this.wat2 = true;
            this[keyName2] = true;
          }
        })
      }
    }
  }
}

(personally, I don't think we need to consider absurdities such as this[keyName1] as examples of a property being written to for this rule, as those are often impossible to accurately understand the resolved key name in static analysis...)

you might have to use parser services

Requiring type information is a breaking change, so I'd prefer to not use it unless we reallllyyyy need it.

Translating this into test cases:

1. test case of computed value this['wat1'] = 123
2. rescursive case of class in constructor

would the following 2 invalid cases capture what you listed?

class Mx {
  private readonly wat1 = true;

  constructor() {
    this['wat1'] = true;
  }
}

class Mx {
  constructor() {
    class Child {
      private readonly foo = true;

      constructor() {
        this.foo = true;
      }
  	}
  }
}