The reason we never added these is two fold:

1. it's really, really rare that people want to use them - I don't think I've seen more than half a dozen rules that actually use them (including the ones in ESLint core).

2. their form ((codePath: { id: string }, node: TSESTree.Node) => void) is incompatible with the node selector signature ((node: TSESTree.Node) => void). This causes TS errors because the code path signatures cannot be assigned to the index signature.

See existing Pr: #2930

Because the usecase is so very rare and it's a difficult problem to solve - we've just opted to not solve it yet.

If you can think of a way to add the definitions without harming the DevX of node selectors then I'm more than happy to have them added to the types!

I must really stress that it's important that we do not impact the DevX of selectors - there are thousands of node selectors written with our types - so we mustn't make them less safe, nor must we make them harder to use just to add types for this fraction of a fraction of a percent case.

Just chiming in here to say that code paths are pretty nice to have.

Code paths are used in a few official ESLint rules, namely no-fallthrough. As you can see from looking at the source code for the rule, it is incredibly short, because all of the heavy-lifting is being done by the code paths feature. In other words, the code paths feature allows us to trivially determine when a particular switch statement case arm is a "fallthrough" case arm.

This functionality is also used in other rules that have to do with switch statements. For example, look at the source code for the newline-between-switch-case rule from eslint-plugin-switch-case. It also uses code paths to trivially detect the fallthrough case.

Of course, code paths are not just useful for rules about switch statements, but for other situations too. They are nice because we can detect certain kinds of situations without having the rule to be type aware, which obviously greatly hinders a rule's performance impact.

As a first baby step, I think that this project should export a CodePath interface at the very least. That would allow plugin authors to perform some manual type assertion. For example:

import type { TSESTree } from "@typescript-eslint/utils";

export const myRule = createRule<Options, MessageIds>({
  create(context) {
    return {
      // We must type assert `never` to `CodePath` because using the nodes
      // inside of a code path can cause problems with TypeScript.
      onCodePathStart(codePath as TSESTree.CodePath) {}
    };
  },

To clarify - it's not that we don't think it's useful - there are some rare usecase for them and they can help solve some problems or simplify others!

Instead what were saying is that unfortunately TS isn't designed to support this usecase well - you can't define an index signature that has one value but also define members with a different, incompatible value.

So in order for us to add the signatures we'd have to break all the existing code that relies on the index signature - which is obviously an intractable solution - breaking 99.99% of cases to support 0.01% isn't good!

I'd welcome someone adding the codepath types - but we just can't add the signatures.

few months ago i tried to add it, but i got stuck with exactly same issue, see #6679

@armano2 What about a PR for just the interfaces?

I'd welcome someone adding the codepath types - but we just can't add the signatures.

@JoshuaKGoldberg I don't think this issue should be closed actually, since I only added the CodePath interfaces in my PR (and not the rule listener methods).

We can't add the listener method definitions to the types without big changes in how TS works.
We rely on the [string]: (TSESTree.Node) => void signature to provide support for esquery selectors and that signature is fundamentally incompatible with the code path selector function signatures (none of which take TSESTree.Node as their first argument).

So unless TS adds a way for us to support both without degrading the experience of esquery selectors - we will have to close this as "fixed as best as we can for now".