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 ind1e65be 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 theelse if (isAllowed === false) statement to remove the indentation, and perhaps move theisAllowed 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 theelse if (isAllowed === false) statement

I don’t think I can remove theisAllowed === false case because it’s possible forisAllowed to beundefined, so I intend to explicitly check if it istrue orfalse in thatif/else if block. If it is neither it will fall back to the base rule.

Perhaps I should move the finalrules.Literal(node); line of the function into anelse block to make that more explicit?

move theisAllowed 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 thecreate function, which makes sense to me. I’m not sure movingisAllowed 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:

typeFoo=Bar[1&number];

typeOther={[0]:3;}typeFoo={[KinkeyofOther]: `${K&number}`;};

typeFoo={[Kin0|1|2]:0;};

typeOthers=[['a'],['b']];typeFoo={[KinkeyofOthers[0]]:Others[K];};

@JoshuaKGoldberg couple of quick questions on those:

typeFoo=Bar[1&number];

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

typeOther={[0]:3;}typeFoo={[KinkeyofOther]: `${K&number}`;};

Since the0 is aTSPropertySignature, not aTSIndexedAccessType, would you still want it to be covered by this newignoreTypeIndexes config? Seems like that should be a separate config?

Also, the3 thereshould be an error, right? So perhapsstring or some other non-numeric literal would be more appropriate for this test case?

typeFoo={[Kin0|1|2]:0;};

As above,TSPropertySignature.

typeOthers=[['a'],['b']];typeFoo={[KinkeyofOthers[0]]:Others[K];};

I’ll add a test to ensure theOthers[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 aTSPropertySignature, not aTSIndexedAccessType, would you still want it to be covered by this newignoreTypeIndexes config?

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

Also, the 3 thereshould be an error, right?

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

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