[Bug] This works for the two specified types of identifiers, but there are other things out there. Private properties, computed keys based on string literals, etc. - which should be tested.

I think you'll want to use getStaticValue to get the static value. getStaticMemberAccessValue in eslint-plugin might be useful as a reference as well, not sure.

Btw, sorry, I realize I suggested these two checks in #10670 (comment) and now am kind of going against that. If this utility were only used internally and by no-deprecated that'd be fine. But I'm remembering now that this is also exported publicly under @typescript-eslint/type-utils. We'll need it to be more generalized.

Thank you for the feedback!
I think Private properties could be supported by 3b3520b.

However, I don't quite understand the support for computed keys. Could you please provide more information?

My understanding is that for cases where AST_NODE_TYPES.Property is passed as the first argument to valueMatchesSpecifier, and the key is a computed key, we should handle it in that context. Is that correct?
（I was under the impression that an AST_NODE_TYPES.Identifier within AST_NODE_TYPES.Property would be passed as an argument...）

If possible, it would be very helpful if you could provide some concrete test cases or examples to guide the implementation.🙇‍♂️
I would appreciate it if you could teach me for my learning. (Also for the future!😂)

I appreciate the questions! Here's a test case I was thinking of:

[
  `
  class MyClass {
    ['computed prop'] = 42;
    value = this['computed prop'];
  }`,
  `'computed prop'`,
],

...but now I'm not so sure. We don't have existing code paths for this, and I'm not sure how we'd want to handle differences in quotes ('computed prop' vs. "computed prop"). cc @typescript-eslint/triage-team - for now I think it's fine to avoid those types of keys, and treat them as a followup issue?

I think handling the computed properties quotations' on the code side isn't scary due to node.value being the "cooked" value (and also we have the static member access helpers), but yeah it requires a syntax decision in the selector. If privateProp matches this.#privateProp then maybe multi word prop should match this['multi word prop'] without any extra syntax? Similarly that would sort of imply that aProp would match this['aProp'] in addition to this.aProp... which seems reasonable?

Thank you for the advice.
I’ve added support for the literal case in 0e61bcf — I’d appreciate it if you could take a look!

[Bug] What if the variable comes from a dynamic package import?

declare const fs: typeof import("fs");

fs.exists;
// ~~~~~~

Using the scope manager to get to the variable's local definition is one step. You might be able to get this to work with more AST+scope work. Or maybe it'd be easier to use TypeScript types and/or symbols? Or some combination of them? YMMV.

I’ve added support for the dynamic import case as well.1578137