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

The list for well-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 JavaScript symbol exists on another ts.Type 🤔

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

const escapedMemberName = ts.escapeLeadingUnderscores(staticAccessValue);
const symbolMemberMatch = type.getSymbol()?.members?.get(escapedMemberName);

return (
  symbolMemberMatch ?? tsutils.getPropertyOfType(type, escapedMemberName)
);

I've looked into the SymbolObject but couldn't find a way to check against an arbitrary symbol (not to be confused with ts.Symbol).

Because of this, I've created a function to map between known symbols and their string representation, which are passed to tsutils.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:

const staticSymbol = Symbol.for('static symbol');

interface Bar {
  [staticSymbol]: () => void;
}

interface Foo extends Bar {}

class Clazz implements Foo {
  // should be reported
  async [staticSymbol]() {}
}

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

function getWellKnownStringOfSymbol(symbol: symbol): string | null {
  for (const [key, value] of Object.entries(Symbol)) {
    if (symbol === value) {
      return key;
    }
  }

  return null;
}

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 from Symbol.prototype.toString() with a regex (which I really didn't want to do), but I didn't think of iterating the global Symbol'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 thread https://discord.com/channels/1026804805894672454/1322853884292497418

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

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 although nodeMember is type ts.TypeElement | ts.ClassElement, node is type TSESTree.Node.

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

• Simpler: use an as to correct TypeScript's understanding of node's type to be NodeWithKey (which will need to be exported from misc.ts)
• More aligned with how most of our typed lint rules go: instead of iterating over the tsNode.members, iterate over the members of node

The latter is probably a lot more work and changes the existing code. So I think the as 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 although nodeMember is type ts.TypeElement | ts.ClassElement, node is type TSESTree.Node.

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

• Simpler: use an as to correct TypeScript's understanding of node's type to be NodeWithKey (which will need to be exported from misc.ts)
• More aligned with how most of our typed lint rules go: instead of iterating over the tsNode.members, iterate over the members of node

The latter is probably a lot more work and changes the existing code. So I think the as 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

class MyClass {
  ''(): void { }
}
class MySubclass extends MyClass {
  async ''(): Promise<void> { }
}

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

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

cross-linking discord thread https://discord.com/channels/1026804805894672454/1322853884292497418