Fixes #1340

Reproducing the problem

This is an interesting one.

Let's consider this really simplified implementation of Paths:

type SimplifiedPaths<T> = T extends object
	? {
		[P in keyof T]: P | `${P & string}.${SimplifiedPaths<T[P]> & string}`;
	}[keyof T]
	: never;

type T = SimplifiedPaths<{a: {b: {c: string}; d: number}; e: boolean}>;
//=> 'a' | 'e' | 'a.b' | 'a.d' | 'a.b.c'

Now, let's recreate the problem in #1340 using this simplified implementation:

type Foo<T> = {bar: {baz: T}};
type Test<T> = SomeTypeWithConstraint<Foo<T>, 'bar.baz'>; // ✅ Works

type SomeTypeWithConstraint<T, _U extends SimplifiedPaths<T>> = never;

Everything works fine here. SimplifiedPaths is able to figure out that 'bar.baz' is a valid path for Foo<T>.

And, if you intentionally instantiate SomeTypeWithConstraint with some incorrect path, then you'd see that the complete value for SimplifiedPaths<Foo<T>> is 'bar' | 'bar.baz' | `bar.baz.${SimplifiedPaths<T> & string}`, which is perfect!

A small change that breaks it

Now let’s make a small change to SimplifiedPaths:

type SimplifiedPaths<T> = T extends object
	? {
		[P in keyof T]: P | (SimplifiedPaths<T[P]> extends infer SubPaths
			? `${P & string}.${SubPaths & string}`
			: never);
	}[keyof T]
	: never;

type T = SimplifiedPaths<{a: {b: {c: string}; d: number}; e: boolean}>;
//=> 'a' | 'e' | 'a.b' | 'a.d' | 'a.b.c'

The only difference is that we first capture SimplifiedPaths<T[P]> into SubPaths and then use that.

Looks harmless, but this now causes an error in our SomeTypeWithConstraint instantiation:

type Foo<T> = {bar: {baz: T}};
type Test<T> = SomeTypeWithConstraint<Foo<T>, 'bar.baz'>; // 💥 Errors

type SomeTypeWithConstraint<T, _U extends SimplifiedPaths<T>> = never;

If you inspect the error, SimplifiedPaths<Foo<T>> now looks like this:

'bar' | ('baz' | (SimplifiedPaths<T> extends infer SubPaths
    ? `baz.${SubPaths & string}`
    : never) extends infer SubPaths 
        ? `bar.${SubPaths & string}`
        : never)

What changed?

Now, the entire subpath chain is wrapped in conditionals that depend on SimplifiedPaths<T>. That makes even 'bar.baz' indirectly dependent on T.

So, 'bar.baz' is no longer a clearly known union member. It is buried inside generic-dependent conditionals, which is why the constraint fails.

Why did Paths extract the recursive result in the first place?

This was done to handle bracketNotation correctly.

If a subpath starts with bracket notation, we must not insert a dot before it. So the caller needs to know what the recursive result looks like before deciding whether to join with . or not. And that is what introduced the generic dependency problem.

Refer to the following lines in the existing implementation:

The fix

This PR moves dot handling into the recursive step itself.

Instead of the caller deciding whether to add a dot, each recursive subpath now returns paths that are already correctly prefixed.

Because of that:

• The caller no longer needs to extract the recursive result into an intermediate type.
• The recursive call can be used directly.
• The full path chain is no longer wrapped in generic-dependent conditionals.

As a result, TS can simplify known prefixes like 'bar.baz', and the constraint works as expected.

Additional improvement

Additionally, this also uncollapses some paths that were previously getting collapsed.

For example, earlier:

Paths<{a: {[x: string]: {b: string; c: number}}}>

returned:

'a' | `a.${string}`

This effectively collapsed `a.${string}.b` and `a.${string}.c` into just `a.${string}`. But those paths do not actually collapse into `a.${string}`. This was only happening because of a limitation in the previous implementation.

type T = `a.${string}` | `a.${string}.c` | `a.${string}.b` // TS doesn't collapse this
//=> `a.${string}` | `a.${string}.c` | `a.${string}.b`

The issue was that the subpath being returned for 'a' was string | `${string}.b` | `${string}.c` which collapses to just string. When that gets joined with 'a', the final result becomes only 'a' | `a.${string}`.

So even though the entire result didn't require any collapsing, it happened because the subpath had already collapsed.

With the updated logic, subpaths are prefixed with a dot. In this case, the subpath now becomes:

`.${string}` | `.${string}.b` | `.${string}.c`

This union does not collapse. So when joined with 'a', we correctly get:

'a' | `a.${string}` | `a.${string}.b` | `a.${string}.c`

So this PR also removes any unnecessary collapsing.

Paths<{[x: string]: string; a: string}>