[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 usegetStaticValue to get the static value.getStaticMemberAccessValue ineslint-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 byno-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 by3b3520b.

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

My understanding is that for cases whereAST_NODE_TYPES.Property is passed as the first argument tovalueMatchesSpecifier, and the key is a computed key, we should handle it in that context. Is that correct?
（I was under the impression that anAST_NODE_TYPES.Identifier withinAST_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 tonode.value being the "cooked" value (and also we have the static member access helpers), but yeah it requires a syntax decision in the selector. IfprivateProp matchesthis.#privateProp then maybemulti word prop should matchthis['multi word prop'] without any extra syntax? Similarly that would sort of imply thataProp would matchthis['aProp'] in addition tothis.aProp... which seems reasonable?

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

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

declareconstfs:typeofimport("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