FWIW, this looks good to me.
The only difference with my implementation is that I reported invalid nodes in this statement, similar to "Check if the node is a readonly class property". This way, we can return early which should be faster?

Also, good catch for the union types - this was something that I overlooked.

@timdeschryver Thanks! I refactored things a little in d1e65be so if any of the four ignorable TypeScript rules are triggered it will report early. Is that better?

Yea, this should work.
If we go into more details I would remove the else if (isAllowed === false) statement to remove the indentation, and perhaps move the isAllowed logic into its own method.

Keep in mind that I'm not a member of typescript-eslint 😅

@timdeschryver Realized I never responded to this, sorry - and thank you for the feedback.

remove the else if (isAllowed === false) statement

I don’t think I can remove the isAllowed === false case because it’s possible for isAllowed to be undefined, so I intend to explicitly check if it is true or false in that if/else if block. If it is neither it will fall back to the base rule.

Perhaps I should move the final rules.Literal(node); line of the function into an else block to make that more explicit?

move the isAllowed logic into its own method

Looking at a few other rule definitions at random it does seem like they keep the core rule logic in the create function, which makes sense to me. I’m not sure moving isAllowed into its own function would improve readability, and feels like it would simply cause people to have to jump to look elsewhere for what is essentially the meat of the rule.

Feel free to push back if you (or @JoshuaKGoldberg?) disagree though, and I will happily take another look.

No problem @davecardwell !
Thanks for the elaboration, that does make sense.

Heh, it's a pity this docs page doesn't use the newer tabbed format others do. No need to change in this PR though; I'm going to try to make docs a bit more automated soon.

A few edge cases we'll also want to test for:

type Foo = Bar[1 & number];

type Other = {
    [0]: 3;
}

type Foo = {
  [K in keyof Other]: `${K & number}`;
};

type Foo = {
  [K in 0 | 1 | 2]: 0;
};

type Others = [ ['a'], ['b'] ];

type Foo = {
  [K in keyof Others[0]]: Others[K];
};

@JoshuaKGoldberg couple of quick questions on those:

type Foo = Bar[1 & number];

Sure, I check for union types so intersection should be covered too! Thanks.

type Other = {
    [0]: 3;
}

type Foo = {
  [K in keyof Other]: `${K & number}`;
};

Since the 0 is a TSPropertySignature, not a TSIndexedAccessType, would you still want it to be covered by this new ignoreTypeIndexes config? Seems like that should be a separate config?

Also, the 3 there should be an error, right? So perhaps string or some other non-numeric literal would be more appropriate for this test case?

type Foo = {
  [K in 0 | 1 | 2]: 0;
};

As above, TSPropertySignature.

type Others = [ ['a'], ['b'] ];

type Foo = {
  [K in keyof Others[0]]: Others[K];
};

I’ll add a test to ensure the Others[0] part is covered.

Great questions!

check for union types so intersection should be covered too

Bar[1 & number] is a bit different syntax from ${K & number}. I think it'd be good to have an explicit test for both. The code right now might not differentiate, but it's ripe for future refactors to miss it.

Since the 0 is a TSPropertySignature, not a TSIndexedAccessType, would you still want it to be covered by this new ignoreTypeIndexes config?

I'm not requesting changes to logic, just that it be covered. Agreed that they're different things -- the tests should validate that ignoreTypeIndexes doesn't remove the complaint on it.

Also, the 3 there should be an error, right?

Yes. That's already covered though; I'm really more interested in the TSPropertySignature.

@JoshuaKGoldberg Thank you for clarifying. In af1ddb7 I added support for intersection types, nesting of union/intersection types, and the additional invalid test cases you suggested.