HasRequiredKeys discussion

[a-non-a-mouse]

We already had this type in our repo and I noticed it's in type-fest. There are some contradictions between our types and type-fest's and I believe ours are more correct as it's more honest wrt what code actually requires. If const foo: type = {} is valid, ours returns false for HasRequiredKeys<type>, whereas type-fest sometimes returns true:

type HasRequiredKeys<T> = Record<string, never> extends T ? false : Partial<T> extends T ? false : true;

type A = HasRequiredKeys<Record<string, unknown>>;             // TF: true; this: false
type B = HasRequiredKeys<Record<string, never>>;               // TF: true; this: false
type C = HasRequiredKeys<{ id: number; [key: string]: any; }>; // true
type D = HasRequiredKeys<{}>                                   // false
type E = HasRequiredKeys<object>                               // false
type F = HasRequiredKeys<{x: number}>                          // true
type G = HasRequiredKeys<{x?: number}>                         // false
type H = HasRequiredKeys<{ a: string; b?: number }>;           // true
type I = HasRequiredKeys<{ a?: string; b?: number }>;          // false
type J = HasRequiredKeys<unknown>;                             // TF: error; this: false
type K = HasRequiredKeys<any>;                                 // TF: true; this: false
type L = HasRequiredKeys<{ readonly x: number }>;              // true
type M = HasRequiredKeys<{ [key: number]: string }>;           // TF: true; this: false
type N = HasRequiredKeys<{ a: string } & { b?: number }>;      // true
type O = HasRequiredKeys<{ a?: string } | { b: number }>;      // TF: true; this: false
type P = HasRequiredKeys<[number, string]>;                    // true
type Q = HasRequiredKeys<[number, string?]>;                   // true
type R = HasRequiredKeys<[]>;                                  // TF: true; this: false
type S = HasRequiredKeys<[number?]>;                           // TF: true; this: false

[som-sm]

Index signatures should return false, so all the following instantiations should return false.

type A = HasRequiredKeys<Record<string, unknown>>;             // TF: true; this: false
type B = HasRequiredKeys<Record<string, never>>;               // TF: true; this: false
type M = HasRequiredKeys<{ [key: number]: string }>;           // TF: true; this: false

Our type has a constraint of object on it, so it cannot be instantiated with unknown, which is fine.

type J = HasRequiredKeys<unknown>;                             // TF: error; this: false

Instantiating with any should return boolean IMO.

type K = HasRequiredKeys<any>;                                 // TF: true; this: false

And in this case as well, it should return boolean (false | true).

type O = HasRequiredKeys<{ a?: string } | { b: number }>;      // TF: true; this: false

[a-non-a-mouse]

I added some array cases (P-S) above. I'm not 100% certain on those, but believe the empty array types should return false.

K (any) & O (union) are debatable, though I personally believe they should both be false per this simple test:

const x: K | O = {}; // valid

Type J (unknown) is the only one I'm on the fence about. I think erroring is fine. I also think false is fine.

[som-sm]

Yeah, these should also return false.

type R = HasRequiredKeys<[]>;                                  // TF: true; this: false
type S = HasRequiredKeys<[number?]>;                           // TF: true; this: false

And, something like string[] should also return false.

K (any) & O (union) are debatable, though I personally believe they should both be false per this simple test:

const x: K | O = {}; // valid

What is this test, and what is it trying to demonstrate? K and O are both booleans, so {} should not be assignable to a boolean.

[som-sm]

What is this test, and what is it trying to demonstrate? K and O are both booleans, so {} should not be assignable to a boolean.

If you mean the following:

const t1: any = {}

const t2: { a?: string } | { b: number } = {}

Then this is the false case.

Consider the following now:

const t1: any = {b: 1}

const t2: { a?: string } | { b: number } = {b: 1}

This is the true case, so it may or may not have required keys, hence boolean.

This is still contrived. I feel like something like HasRequiredKeys will mostly be used at the type level, so returning boolean is a better choice. Do you have a more realistic example?

[a-non-a-mouse]

Yeah, I was being a bit imprecise with my shorthand, sorry about that. Let's clarify the intent:

any:

When I say const x: any = {}, I’m pointing out that any essentially functions as the ultimate 'bag of anything' (including nothing). If any can be represented by {}, it’s hard to argue it requires a key. Treating it as an index signature feels more 'honest' than returning boolean

Union:

The union type { a?: string } | { b: number } is the more confusing one.

The assignment test, const t2: O = {}, is valid because it satisfies the first member of the union.

The logic: If HasRequiredKeys is meant to answer 'Must I provide a key to satisfy this type?', then for this union, the answer is no.

If we were to return boolean, we’re essentially telling developers "Maybe you do, maybe you don't." While technically accurate in a vacuum, it’s not very helpful for conditional types.

Basically, IMO, HasRequiredKeys should be a 'guarantee' check:

True: You must provide at least one specific key.

False: There is at least one valid state where the object is empty (or only contains optional/index keys).

Widening to boolean for unions or any weakens the utility of the type. If a type can be empty, HasRequiredKeys should probably stay false.

[a-non-a-mouse]

One more point --

If the utility ever returns just boolean, it can't be used as a conditional type at all.

type Result = HasRequiredKeys<O> extends true 
  ? DoSomething 
  : DoSomethingElse;

And in this view, any and the union should definitely return false

Ultimately, the implementation I proposed is essentially just checking extends Partial. This offloads the entire responsibility to TypeScript’s own internal logic. If the compiler agrees that a type is assignable to its partial version, then by definition, it doesn't require keys. I’d rather trust the compiler's definition of assignability than try to manually account for every edge case

[som-sm]

it’s not very helpful for conditional types.

Can you give a practical use case where returning false makes more sense than returning boolean?

If the utility ever returns just boolean, it can't be used as a conditional type at all.

It can be, in fact returning boolean gives more flexibility, you can treat boolean as both true or false, for example:

type HasRequiredKeys<T> = boolean;

type Test1 = HasRequiredKeys<any> extends true
    ? "it's guaranteed to be true here" // guarantees presence of required keys
    : "can be false or boolean"

type Test2 = HasRequiredKeys<any> extends false
    ? "it's guaranteed to be false here" // guarantees absence of required keys
    : "can be true or boolean"

And, you can also evaluate both branches if you distribute the boolean:

type HasRequiredKeys<T> = boolean;

type Test1 =
  HasRequiredKeys<any> extends infer Res
    ? Res extends true
      ? "branch A"
      : 'branch B'
    : never; // Unreachable

type T = Test1
//   ^? type T = "branch A" | "branch B"

If you return false for boolean, you lose this flexibility. And most of our types return boolean in such cases, and that approach has worked well in practice.

Ultimately, the implementation I proposed is essentially just checking extends Partial. This offloads the entire responsibility to TypeScript’s own internal logic. If the compiler agrees that a type is assignable to its partial version, then by definition, it doesn't require keys. I’d rather trust the compiler's definition of assignability than try to manually account for every edge case

Not entirely true, your implementation also uses two conditionals. Just using the extends Partial conditional would not produce the desired results with index signatures:

type HasRequiredKeys<T> = Partial<T> extends T ? false : true;

type T = HasRequiredKeys<{[x: string]: number}>
//   ^? type T = true

So, at times you need to handle certain cases explicitly.

[som-sm]

Not entirely true, your implementation also uses two conditionals. Just using the extends Partial conditional would not produce the desired results with index signatures:

And, for objects containing no required keys, the extends Partial conditional isn't even being used:

type HasRequiredKeys<T> = Record<string, never> extends T ? false : 'this does not matter';

type T = HasRequiredKeys<{a?: string}>
//   ^? type T = false

If you just rely on the extends Partial conditional, for mixed unions you'd start getting true, which is clearly incorrect.

type HasRequiredKeys<T> = Partial<T> extends T ? false : true;

type T = HasRequiredKeys<{a?: string} | {b: number}>
//   ^? type T = true

[a-non-a-mouse]

Can you give a practical use case where returning false makes more sense than returning boolean?

I guess it's more about philosophy. A "HasN" check, in my mind, returns true or false. Your two examples read as broken to me.

type Test1 = HasRequiredKeys<any> extends true
    ? "it's guaranteed to be true here" // true branch
    : "can be false or boolean"         // false branch.  NOT `false or boolean` branch

If you return boolean you are effectively saying "you MUST check the branch you care about first" which ends up being a hidden footgun. For various reasons, not everyone does 100% of the time. If I care that a result is false, but check extends true, that should be a perfectly valid pattern because I expect HasRequiredKeys to return true | false.

These two should be identical:

HasRequiredKeys<T> extends true ? A : B;
HasRequiredKeys<T> extends false ? B : A;

Not entirely true, your implementation also uses two conditionals. Just using the extends Partial conditional would not produce the desired results with index signatures:

Eh, I'm not really handling edge cases there, I'm working around TS's treatment of never. The logic Partial<T> extends T is sound; the first conditional just normalizes the never case.

Anyway...

I think the test cases are more important than discussions about internals, sorry for bringing up that bit of sidetracking :) Personally I think this test should be the decision maker:

const x: Type = {}; // If this is valid, HasRequiredKeys<Type> should be false

But it's not my call.

[som-sm]

If you return boolean you are effectively saying "you MUST check the branch you care about first" which ends up being a hidden footgun.

I wouldn't call it a hidden footgun, it's rather a deliberate decision. And, if you want HasRequiredKeys to only ever return true or false, then just don't instantiate it with any or a mixed union, both of which can be easily checked. By returning false for boolean, you're making a decision on behalf of the user that if there's even a single case where there might not be a required key, just return false. However, by returning boolean, you leave that decision to the user, which I feel is the more appropriate choice for a library.

Eh, I'm not really handling edge cases there, I'm working around TS's treatment of never. The logic Partial extends T is sound; the first conditional just normalizes the never case.

That's not true. The examples given above clearly demonstrate that the first conditional is handling more than just the never case. Please refer to the examples above.

---

Ultimately, neither approach is outright incorrect. It just comes down to how much flexibility you want to give to the end user.

[a-non-a-mouse]

I think it's absolutely a footgun if extends true ? A : B and extends false ? B : A work differently than one another in any circumstances. The name of the util itself implies that it's binary. If the util wants to give up and say "I dunno", that's a perfectly reasonable stance, but in that case I'd strongly advocate for triggering an error (e.g. what it does now for unknown/null) as opposed to silently returning boolean.