Hmmm, the comments in this PR tell an interesting story for this case: #3009

This behavior seems to be intentional...
a) autofix is not available when there is a (nonempty) extends list (because it... can't really be fixed?)
b) the rule won't report when there's more than one property in the interface, regardless of the extends list.

The case you bring up falls where those two entirely separate behaviors interact

I'm surprised this has never come up before! Sometimes I just need to be able to access properties by index. This particular case is for some custom error logging where I want to grab all properties off of an incoming error, but exclude a few by name. TS complained at me for not having an index signature, so I added this. Here's my real world use case for the type I ran into this on

export interface IIndexableAxiosError extends AxiosError {
  [key: string]: unknown;
}

I'm surprised this has never come up before! Sometimes I just need to be able to access properties by index.

It's generally very, very rare that you want to add an unbounded indexer to an existing type!
It introduces a fair bit of unsafety (eg you can easily pass an invalid key).
Most people don't want to index an object with known keys using a raw string typed variable.

Or a safer way to do things would be eg

declare const key: string;
declare const base: AxiosError;
if (base.hasOwnProperty(key)) {
  base[key as keyof typeof base];
}

I don't think there's a really compelling, broadly-applicable reason to allow this within the rule.
I think leaving it as an error and having the user add a disable comment explaining why they're opting in to an indexer is a better outcome than just ignoring it and making it look like a false negative.

ok, fair enough. I've updated my code to grab the value using let val: unknown = error[key as keyof AxiosError]; which does feel a bit safer to me than what I was doing before. So thanks for that.

However, given my original code it still feels kinda wrong to recommend that an extended interface with an added index be recommended to use as as Record instead. That recommendation doesn't feel right to me since it can't really be done. Perhaps for this unique situation it could have a different error message?

ok, so I've actually run into this issue yet again in a slightly different way. I have a large "base" interface and then I make several smaller and specific interfaces with Pick or Omit` for different use cases. I need them to be indexable.

Here's a playground link for everything below.

I could go this route:

interface ILargeBaseA {
  foo: string;
  bar: number;
  baz: boolean
  qux: string[];
  zop: null | string;
}

interface IStringsOnlyA extends Pick<ILargeBaseA, 'foo' | 'qux' | 'zop'> {
  [key: string]: string | string[] | null;
}

function getValA(obj: IStringsOnlyA, key: string) {
  return obj[key];
}

which works great and the return type of getValA is correctly inferred as string | string[] | null but this rule again complains that it would prefer it to be a Record.

Ok, I'll lean into that and move the indexing to the base class and use a Record as it wants

interface ILargeBaseB {
  [key: string]: string | string[] | boolean | number | null;
  foo: string;
  bar: number;
  baz: boolean
  qux: string[];
  zop: null | string;
}

type IStringsOnlyB = Pick<ILargeBaseB, 'foo' | 'qux' | 'zop'>;

function getValB(obj: IStringsOnlyB, key: string) {
  return obj[key];
}

ESLint no longer complains, but now I lose my index signature it it just infers an any type from that function. Using "strict":true this will give a compilation error

Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'IStringsOnlyB'.
  No index signature with a parameter of type 'string' was found on type 'IStringsOnlyB'.

as far as I can tell, my only workaround here is to disable this rule since it just seems flat out wrong my my use case here.

a possible workaround I might be able to do is use keyof like this, which accomplishes it all, but it may not always be feasible in certain situations

interface ILargeBaseC {
  [key: string]: string | string[] | boolean | number | null;
  foo: string;
  bar: number;
  baz: boolean
  qux: string[];
  zop: null | string;
}

type IStringsOnlyC = Pick<ILargeBaseC, 'foo' | 'qux' | 'zop'>;

function getValC(obj: IStringsOnlyC, key: keyof IStringsOnlyC) {
  return obj[key];
}

Why not something like

type IStringsOnlyC = Pick<ILargeBaseC, 'foo' | 'qux' | 'zop'> & Record<string, string | string[] | null>;

Or more generally

type IndexableThing = T & Record<string, values of T>;

What's wrong with an intersection here?

I do not use intersection types often, thanks for the reminder. ok, good call there.

but again, perhaps the rule could make more intelligent recommendations/fixes for cases like these?

I think:

• It is always safe to autofix { [x: string]: unknown } to Record<string, unknown>
• It is NOT SAFE in general to autofix Record<T, unknown> into { [x: T]: unknown } unless T is known to be a non-union (see [consistent-indexed-object-style] fixer produces invalid code and deletes comments #4730)
• It is NOT SAFE to autofix interface Foo { [x: string]: unknown } to type Foo = Record<string, unknown> due to declaration merging, but the danger is low

All the above are what the rule considers as "indexed object". However there are a few other types:

type A = {
  x: 1;
  [y: number]: 2;
};

interface B {
  x: 1;
  [y: number]: 2;
}

type C = { x: 1 } & Record<number, 2>;

interface Base {
  x: 1;
}

interface D extends Base {
  [y: number]: 2;
}

To me, the rule only reporting D but not A or B is somewhat arbitrary, since they represent the same style of composition.

Marking as evaluating community engagement as this has been in triage for a while and there isn't a clear best path forward.

3 months later and this request has received 0 community reactions.
As per our workflow guidelines - we are taking this as signal that this check is not important to the broader community and are thus rejecting the proposal. Thanks for filing!