pick: pick should return Partial<Pick<T,K>>

[florian-lackner365]

tl;dr: pick should return Partial<Pick<T,K>>. It might be possible to specialize to Pick<T,K> for certain types K. Would you be willing to accept a contribution?

Consider this code:

const t = { a: 1, b: 2, c: 3 };
type T = typeof t;
const k = [Math.random % 2 === 0 ? 'a' : 'b'] as const; // readonly ['a' | 'b']
const res = pick(t, k); // Pick<T, 'a' | 'b'>
// but res === { a: 1 } or { b: 2 } <-> Pick<T, 'a'> | Pick<T, 'b'>

The easy solution to fix this would be to return Partial<Pick<T, K>> from pick. However, that's annoying for situations where we know that all Ts are going to be in K, like: pick(x, ['a', 'b']). In this case we want Pick<X, 'a' | 'b'>.

The fix in TS seems to be complicated though. I tried a little bit and got tuple detection to work. I could prepare a PR that would fix the type for general arrays to Partial<Pick<T, K>> and to Pick<T, K> if the user passes a tuple. That would deblock a common case, while still being wrong in the example I gave.

What do you think? Would you be willing to accept such a contribution? Do you prefer the status quo?

[Seojooyeon-creat]

Hi! I'd like to contribute a fix for this. Before opening a PR, I wanted to check in first.

Proposed approach

I implemented the fix using a conditional return type with tuple detection — no extra overloads needed:

export function pick<T extends Record<string, any>, Keys extends ReadonlyArray<keyof T>>(
  obj: T,
  keys: readonly [...Keys]
): number extends Keys['length'] ? Partial<Pick<T, Keys[number]>> : Pick<T, Keys[number]>

• readonly [...Keys] forces TypeScript to infer tuple types for array literals like ['a', 'b']
• number extends Keys['length'] distinguishes tuple (length is a literal like 2) from variable-length array (length is number)
• Result: tuple → Pick<T, K>, dynamic array → Partial<Pick<T, K>>

Context I'm aware of

I noticed that a similar fix was applied to omit (#1498) and then reverted (#1595) in favor of "a simpler, stricter typing model." That fix used overloads with PropertyKey[], which is a different approach from the single-signature conditional type I'm proposing here.

Would you be open to this direction for pick? Happy to open a PR if so.

[florian-lackner365]

I like your fix 👍

(However I can't speak for the maintainers of course)

[Seojooyeon-creat]

I like your fix 👍

(However I can't speak for the maintainers of course)

Thank you for liking it!!👍