Should TS suggest a new QF for properties that start from _ (Declare private property '_bar')? Or Declare property '_bar' QF should handle that?

cc @DanielRosenwasser

Yeah, it sounds like the original quick fix is asking us to change the existing quick fix to add a private modifier to the property in TypeScript files, and maybe a /** @private */ doc comment in a JavaScript files?

What's preferable here?

@DanielRosenwasser

TypeScript

class Foo {
  constructor() {
    this._bar = 1; /* Declare property 'bar' */
  }
}

After QF

class Foo {
  private _bar: number;
  constructor() {
    this._bar = 1;
  }
}

Is it a right example for TypeScript?

The following example is a valid JavaScript code

class Foo {
  constructor() {
    this._bar = 1;
  }
}

Where do we need to add /** @private */ JSDoc?

Yeah, I guess the JS case doesn't need that... hmm.

But yes, I think the TS example you had is what what the quick fix should do. It's not clear whether it should be a separate action or not though.

I'm inclined to experiment with keeping it as part of the same action and seeing if users are unhappy about it.

But then I think there will be a question of "why don't you always make my properties private regardless of the _?"

@DanielRosenwasser I personally don't tend to prefix privates with underscores, so I'd like it to be a separate action.

Of course if it's a separate action you'll soon have "why isn't there an action for protected if you allow private and public?".

Of course if it's a separate action you'll soon have "why isn't there an action for protected if you allow private and public?".

I think, better to make a new action for that case. We can start by adding new QF action for private declaration, and see if it makes sense to add QF action for protected properties. What do you think?

cc @DanielRosenwasser @JacksonKearl

Adding just a separate QF for private seems fine for now.