[no-assignment-of-untracked-properties-used-in-tracking-contexts] False positive with constructors?

Not absolutely sure about that. I’m getting that warning for some assignments in a constructor. That is, I have a native JS class that uses @computed in it and sets in the constructor some properties that are used in that @computed… should this assignment be done via Ember.set or is this a false-positive?

[bmish]

I am assuming you are talking about this example:

import Component from '@ember/component';
import { computed } from '@ember/object';

export default class MyComponent extends Component {
  constructor() {
    super();

    this.x = 123; // this should use `set` according to ember/no-assignment-of-untracked-properties-used-in-tracking-contexts
  }

  @computed('x')
  get myProp() {
    return this.x;
  }
}

Using set in the constructor seems like a good thing to do for consistency, given that we should be using set when modifying this property anywhere else in the file.

But is it actually required to use set for this property in the constructor? Probably not? So I’d be open to any of these changes to the rule:

1. Update the rule to always ignore constructors.
2. Add an ignoreConstructors option (default true).
3. Add an ignoreConstructors option (default false).
4. No change.

@rwjblue @pzuraq @mongoose700 thoughts?

[bmish]

Hmm! I’m a big fan of the consistency argument. It’s confusing to use set in some places but assignment in other places for the same property. So perhaps enforcing consistency even if set isn’t needed in the constructor is actually a feature and not a bug.