I'm not sure if there's a better way to map a symbol to its string counterparttsutils.getWellKnownSymbolPropertyOfType is expecting.

The list forwell-known symbols isn't long, but this will still require maintaining this mapping.

If this approach makes sense, this list can be expanded to support other well-known symbols.

Is there a reason we need to stick to well-known symbols? I'd think we should go with any detected symbol, no?

Hmm, I might be missing something, but I'm not entirely sure how to check if a JavaScriptsymbol exists on anotherts.Type 🤔

Here's how existing code checks if an inherited type has astring symbol:

constescapedMemberName=ts.escapeLeadingUnderscores(staticAccessValue);constsymbolMemberMatch=type.getSymbol()?.members?.get(escapedMemberName);return(symbolMemberMatch??tsutils.getPropertyOfType(type,escapedMemberName));

I've looked into theSymbolObject but couldn't find a way to check against an arbitrarysymbol (not to be confused withts.Symbol).

Because of this, I've created a function to map between known symbols and their string representation, which are passed totsutils.getWellKnownSymbolPropertyOfType to check if they exist on the inherited type.

Edit: I don't think it's feasible to iterate the inherited parent's nodes, as a function may be higher up the inheritance chain:

conststaticSymbol=Symbol.for('static symbol');interfaceBar{[staticSymbol]:()=>void;}interfaceFooextendsBar{}classClazzimplementsFoo{// should be reportedasync[staticSymbol](){}}

Hmm gotcha thanks. cc@kirkwaiblinger - I'm fine with this as a patchwork helper, with as little hardcoding as possible.

functiongetWellKnownStringOfSymbol(symbol:symbol):string|null{for(const[key,value]ofObject.entries(Symbol)){if(symbol===value){returnkey;}}returnnull;}

And, sorry for dropping the ball on this again 🤦 there's something about symbols that makes me instinctively forget the conversation...

I've updated the PR to not hard-code well-known symbols, thanks!

The only alternative I had in mind for not hard-coding was to extract the value fromSymbol.prototype.toString() with a regex (which I really didn't want to do), but I didn't think of iterating the globalSymbol's keys.

This means that arbitrary symbols (e.g.Symbol.for('foo')) won't be reported by the rule though.

Yeah I don't see a way to work for arbitrary symbols 😞

cross-linking discord threadhttps://discord.com/channels/1026804805894672454/1322853884292497418

This is enough to pass the test suit but there are additional types available to satisfygetStaticMemberAccessValue.

This is necessary mainly for type-checking, and I don't know if this can realistically have a runtime scenario. Please let me know if this should be handled differently (currently, there is no coverage for this).

I don't believe this can realistically be a runtime scenario. I think the real issue here is that althoughnodeMember is typets.TypeElement | ts.ClassElement,node is typeTSESTree.Node.

The two strategies I'd think could be good would be:

• Simpler: use anas to correct TypeScript's understanding ofnode's type to beNodeWithKey (which will need to be exported frommisc.ts)
• More aligned with how most of our typed lint rules go: instead of iterating over thetsNode.members, iterate over the members ofnode

The latter is probably a lot more work and changes the existing code. So I think theas strategy would be reasonable.

Yes, I've started with a type-assertion on my initial implementation but I wasn't sure if there's a realistic case where this would explode.

I updated the code to use a type assertion, as the second option seems to be a lot more work.

[Testing] One thing under test per case please (https://typescript-eslint.io/contributing/pull-requests#granular-unit-tests)

I don't believe this can realistically be a runtime scenario. I think the real issue here is that althoughnodeMember is typets.TypeElement | ts.ClassElement,node is typeTSESTree.Node.

The two strategies I'd think could be good would be:

• Simpler: use anas to correct TypeScript's understanding ofnode's type to beNodeWithKey (which will need to be exported frommisc.ts)
• More aligned with how most of our typed lint rules go: instead of iterating over thetsNode.members, iterate over the members ofnode

The latter is probably a lot more work and changes the existing code. So I think theas strategy would be reasonable.

Is there a reason we need to stick to well-known symbols? I'd think we should go with any detected symbol, no?

(same as other comment)

(bug)

because

classMyClass{''():void{}}classMySubclassextendsMyClass{async''():Promise<void>{}}

Oh, nice catch! Is there any reason we don't havestrict-boolean-expressions enabled?

Because IIRC both Joshs don't like it hehe. Brad and I both do like it. 🤷‍♂️

cross-linking discord threadhttps://discord.com/channels/1026804805894672454/1322853884292497418