Code fix spelling suggestions for class fields based on lexical scope

Suggestion

Issue raised to separately track discussion started here: https://github.com/microsoft/TypeScript/pull/44648/files#r709632217 as suggested by @sandersn

Right now code fix spelling suggestions for property names are based on the receiver type. When the receiver type is wide, perhaps unknown, further correct candidate names could be collected from the fields in any surrounding classes. This could potentially only apply to private fields, where they can only be used within the class, or extended to all fields.

🔍 Search Terms

spelling, suggestion, code fix, class fields, private fields

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

📃 Motivating Example

class MyClass {
  #brand;
  
  static isMyClass(v: object): v is MyClass {
    return #brad in v; // provide code-fix here: change 'brad' to 'brand'
  }
}

Private field lookup, unlike traditional property look up, is scoped to within the class. This provides a finite, and lexically discoverable, set of candidate field names.

💻 Use Cases

The reciever type can be too wide to use for candidate names in these cases:

• type narrowing checks https://github.com/tc39/proposal-private-fields-in-in
• JavaScript files where static type information has not been added with JSDoc comments.

❔ Questions

from here

• How much does it improve real-world recall?
• How much does it hurt precision?
• Should it only apply to #privates?
• Does iterated lookup hurt performance? (Probably not, but worth thinking about a little.)
• When the type is explicitly any or unknown, shouldn't the editor first suggest a specific type or narrowing for the receiver?

Commencez par la discussion sur la correction du code de suggestion orthographique liée depuis l’issue, y compris la revue de la pull request TypeScript mentionnée. Comparez l’exemple de champ privé aux suggestions existantes sur le type du récepteur et tranchez les questions ouvertes concernant la portée, la précision et les performances ; l’issue ne nomme aucun fichier d’implémentation ni aucun test, et les critères d’achèvement restent indécis.