[Refactor] Aha, a duplication of information! methodNameIsLiteral will always be true if methodNameIsNull is true. So this is using two variables to store a single piece of info. I'd suggest using either a union type or enum to consolidate down to one variable.

For example, the enum form might look something like this (but maybe with different names, I haven't thought too hard about these):

type MethodNameVariant = 'identifier' | 'non-null-literal' | 'null-literal';

node.key as TSESTree.Literal

[Refactor] This as assertion isn't always going to be correct. The TSESTree types are set up to represent all the possible values of properties. The fact that an as was needed to get this code to type check means that the code isn't handling some case that it needs to handle.

Removing the as gives:

Property 'value' does not exist on type 'FunctionExpression | ArrayExpression | ArrayPattern | ArrowFunctionExpression | AssignmentExpression | ... 35 more ... | YieldExpression'.
  Property 'value' does not exist on type 'FunctionExpression'.

...which is true. What if the node's key is a function expression?

class InvalidSample {
  [function () { }]() {
    console.log("Yippee!")
  }
}

This code is wacky (and causes a TypeScript complaint) but someone in the wild might try to run this rule on that code.

Change request: remove all the as assertions from this file, and explicitly handle those odd node edge cases.

Note too that we require high unit test coverage (generally, ~100% if possible) for new rule tests. So this'll need unit tests added for any new logic. You can always run yarn test from packages/eslint-plugin to generate a testing coverage report at packages/eslint-plugin/coverage/lcov-report/index.html (or see the Codecov PR comment for an online viewer).

A lot of consumers don't use noImplicitOverride. I think we'll still want the rule to be able to work for them... which means it'll have to use rule type checking when there isn't an override operator on a method.

Roughly, that means:

1. Grabbing the type of the extended class
2. Checking whether it has a method / function property under the same name

Let's keep conversations threaded, please, so it's easier to have multiple at a time & mark them as open or resolved.

As to how to grab the type of the extended class: you'll need to use the type checker. Have you read our resources on doing that?

• https://typescript-eslint.io/blog/asts-and-typescript-eslint
• https://sourcegraph.com/notebooks/Tm90ZWJvb2s6MTA2OA==
• https://typescript-eslint.io/custom-rules#typed-rules