Bug

<Command.Item value={null}> throws TypeError: Cannot use 'in' operator to search for 'current' in null instead of either accepting null or warning gracefully.

Minimal reproduction

import { Command } from 'cmdk';

export default function Repro() {
  return (
    <Command>
      <Command.Input />
      <Command.List>
        {/* This crashes when rendered: */}
        <Command.Item value={null}>Crash</Command.Item>
      </Command.List>
    </Command>
  );
}

Versions tested: cmdk@1.1.1, react@19.2.4.

Root cause

In dist/index.mjs, the internal useValue helper iterates an array of values and does:

for (let R of n) {
  if (typeof R === "string") return R.trim();
  if (typeof R === "object" && "current" in R)  // <-- crash on null
    return R.current ? ... : ...;
}

typeof null === "object" is the classic JavaScript gotcha — it's truthy here, so the next line "current" in null throws TypeError. The for...of loops over [r.value, r.children, ref] for each <Command.Item>, and if r.value (or r.children) is null, the crash fires deep inside React reconciliation, often surfacing as an unhelpful production stack trace.

Suggested fix

- if (typeof R === "object" && "current" in R)
+ if (R !== null && typeof R === "object" && "current" in R)

(Or use R != null && ... to also skip undefined, though typeof undefined === "undefined" already handles that.)

Real-world impact

We hit this in production: a Directus row with name: null flowed into a <Command.Item value={bin.name}> — every user selecting a particular warehouse hit the same TypeError. Took ~2 hours to track down because the minified production stack trace shows ~30 frames of React reconciliation walk before pointing at the cmdk internal. Adding the null check would have surfaced as a no-op (item just gets a defaulted/skipped value) instead of a hard crash.

Happy to send a PR if helpful.