Fix: add index signature support for Paths

[benzaria]

Closes #1190

Changes

• fix Paths accepts index signature types and output all possible paths.
• refactor: split type into smaller pices and removed unnecessary conditions and repetition in Paths.
• refactor: Updated LiteralUnion to return (string & {}) instead of (string & Record<never, never>).
• add: Introduced EmptyArray and IsEmptyArray types (internal).
• add: Introduced OwnKeys types that extract own proprety keys from object/arrays.

Tests

• add: Added tests for new features and bug fixes.
• update: Updated existing tests to reflect changes.

[sindresorhus]

refactor: Updated LiteralUnion to return (string & {}) instead of (string & Record<never, never>).

Can you elaborate on why that is better? And it needs a test, if possible.

[benzaria]

refactor: Updated LiteralUnion to return (string & {}) instead of (string & Record<never, never>).

Can you elaborate on why that is better? And it needs a test, if possible.

@sindresorhus Its just a visual improvement that does not change the functionality of the type.

I test it using this example and some others should I add a test file?

type LiteralUnion<LiteralType, BaseType extends Primitive> = LiteralType | (BaseType & Simplify<{}>);

// Pass
expectType<LiteralUnion<'foo', string>>({} as (string & {}) | 'foo');
expectType<LiteralUnion<'foo', string>>({} as (string & Record<never, never>) | 'foo');
// Fail
expectType<string>({} as (string & {}) | 'foo');

[som-sm]

Maybe we could return an uncollapsed union like (string & {}) | `${string}.a` | `${string}.b`, but we’d have to decide in what situations we should return an uncollapsed union.

As mentioned here, just adding a check for string wouldn't be sufficient, because there would be other cases as well where the result would get collapsed.

The existing implementation fails in the following cases:

•  type T = Paths<{[x: Uppercase<string>]: {a: string}; C: {a: string}}>;
   //=> Uppercase<string> | `${Uppercase<string>}.a`

  C.a is lost, result should have probably been: Uppercase<string> | (`${Uppercase<string>}.a` & {}) | "C.a"

•  type T = Paths<{a: {[x: string]: number} | {b: number}}>;
   //=> "a" | `a.${string & {}}`

  a.b is lost, result should have probably been 'a' | (`a.${string}` & {}) | 'a.b'.

There would likely be more cases, hence it needs to be thought out properly.

Also, it'd be much easier to review if the PR only fixed the bug and not introduced a bunch of refactoring changes along with it.

[som-sm]

Looks like an irrelevant change.

[som-sm]

Ideally, this should not be part of this PR. It introduces a bunch of refactoring changes, which makes it harder to review the actual bug-related changes.

[som-sm]

Why remove Options['bracketNotation'] extends false conditional in this PR?

[benzaria]

if its not true -> its false there is no in bettwen. bracketNotation extends boolean !

[som-sm]

Why do that in this PR, what's the scope of this PR?

[som-sm]

Why remove Options['bracketNotation'] extends false conditional in this PR?

[benzaria]

Why is the purpose of it in the first place?

[benzaria]

@sindresorhus @som-sm Hey guys, so I wanted to discuss the new changes.
I was able to add the intended behavior and covering edge cases that @som-sm mentioned:

declare const edge1: Paths<{a: {[x: string]: number} | {b: number}}>;
expectType<'a' | 'a.b' | (`a.${string}` & {})>(edge1); // Pass

declare const edge2: Paths<{[x: Uppercase<string>]: {a: string}; C: {a: string}}>;
expectType<'C' | 'C.a' | (Uppercase<string> & {}) | (`${Uppercase<string>}.a` & {})>(edge2); // Pass

declare const stringRecord: Paths<Record<string, {a: number; b: number}>>;
expectType<(string & {}) | `${string}.a` | `${string}.b`>(stringRecord); // Pass

declare const templateRecord: Paths<Record<`on${string}`, {a: number; b: number}>>;
expectType<(`on${string}` & {}) | (`on${string}.a` & {}) | (`on${string}.b` & {})>(templateRecord); // Pass

declare const complexRecord: Paths<Record<number, {a: number; b: number}> & DeepObject>;
expectType<number | `${number}` | 'a' | (`${number}.b` & {}) | (`${number}.a` & {}) | 'a.b' | 'a.b2' | 'a.b3' | 'a.b.c' | ${`a.b2.${number}` & {}} | 'a.b.c.d'>(complexRecord); // Pass

Explaination
Now Paths will return a LiteralUnion for any wide string type like (string, Uppercase<string>, on${number})
For now test are fine but they will fail bcs string !== (string & {}) so we need to go over test and make some changes.

At the moment this it the best result so far, but maybe I can find a way to include the LiteralUnion only if types extends others but that will be triky to achieve.

Also, it'd be much easier to review if the PR only fixed the bug and not introduced a bunch of refactoring changes along with it.

I do apologize for the extra refactoring and changes, but I couldn't stand the compact type and all-in-one approach that was originally used. A best practice is to split the types into reusable pices that do one job. I apologize again 🙏for the mess.

[sindresorhus]

I do apologize for the extra refactoring and changes, but I couldn't stand the compact type and all-in-one approach that was originally used. A best practice is to split the types into reusable pices that do one job.

We are more than happy to have refactoring and readability improvements. What we are trying to tell you is that those changes are better done separately as they make it hard to see the actual changes.

[benzaria]

Okay captain, lets keep it for another PR.
@som-sm I reverted the refactoring changes.

[sindresorhus]

https://github.com/sindresorhus/type-fest/pull/1191/files#r2152241210

[sindresorhus]

https://github.com/sindresorhus/type-fest/pull/1191/files#r2152241210

Bump ⬆️