ts2589 excessively deep on a dot-path type that worked at 4 levels of nesting Solved

Not a dead end, but you need a depth counter. The compiler is not confused, it hit its instantiation budget, and it has no way to know your object bottoms out.

type Prev = [never, 0, 1, 2, 3, 4, 5, 6]

type Path<T, D extends number = 4> =
  [D] extends [never] ? never
  : T extends readonly unknown[] ? never
  : T extends object
    ? { [K in keyof T & string]:
          T[K] extends object ? K | `${K}.${Path<T[K], Prev[D]>}` : K
      }[keyof T & string]
    : never

The thing to internalise is that depth is not the real cost, the cross product is. Nine top keys with seven children each with six each with five is roughly 1,890 distinct string literals, and every one of them is a template literal instantiation the checker has to materialise. Add a level and you multiply, not add.

Capping at 4 means anything deeper falls back to never for the tail, which in practice you handle by accepting string past that depth. Nobody has ever complained about not getting autocomplete at level six.

Worth learning to measure this rather than guessing at it, because the next one will be a different type.

tsc -p . --generateTrace ./trace --incremental false

Then drop trace/trace.json into a trace viewer and look for the wide bars under checkSourceFile and structuredTypeRelatedTo. tsc --diagnostics also prints instantiation counts, and if that number has a comma in an unexpected place you know where you stand before you have read a single line of type code.

In my experience there are three usual culprits: a schema library chain producing a giant inferred type, a dependency shipping enormous conditional types, and exactly this — a path or deep-partial helper that someone wrote when the object was small.

Pragmatic question: do you actually need dot paths at all? config.services.api.http.server.port costs zero type instantiations, autocompletes better, refactors correctly under rename, and is shorter to read. Dot-path types are a genuinely impressive trick that quietly taxes every person who opens that file.

I have removed two of these from codebases and nobody noticed anything except that the editor got faster.

Before you reach for the depth cap, check how config is typed. If it is annotated as Record<string, unknown> or inferred without a const assertion somewhere in the chain, keyof T & string is string rather than a literal union, and then the recursion genuinely has no bottom — that produces the same TS2589 for a completely different reason and the depth cap only hides it.

const config = { ... } as const satisfies AppConfig and see whether the error changes shape.

// @ts-ignore on that line and move on. TS2589 is the compiler being conservative, the type is fine at runtime.