How do Array.prototype.some and Array.prototype.every short-circuit, and what does each of them return for an empty array?

## Two mirror-image questions `Array.prototype.some(callback, thisArg)` and `Array.prototype.every(callback, thisArg)` are the boolean predicate methods. The callback receives `(element, index, array)` and its **truthiness** decides the outcome — not a strict `true`. - `some` asks "does at least one element satisfy this?" It returns `true` as soon as the predicate returns a truthy value, and `false` only after the whole array has been inspected without one. - `every` asks "do all elements satisfy this?" It returns `false` as soon as the predicate returns a falsy value, and `true` only after the whole array passed. They are De Morgan duals: `arr.some(p)` is equivalent to `!arr.every(x => !p(x))`. Writing the double negative is what you do when only one of them reads naturally for the domain. ## Short-circuiting is observable Because the scan stops early, the predicate call count is observable — which matters if it is expensive, or if the array is large: ```js const nums = [1, 3, 5, 8, 9]; let calls = 0; nums.some(n => { calls++; return n % 2 === 0; }); // true calls; // 4 — stopped at 8, never looked at 9 ``` This is the concrete argument against the common alternative `arr.filter(p).length > 0`: `filter` visits every element, runs the predicate on all of them, and builds an array that is discarded one expression later. For a membership question with an expensive predicate or a long array, `some` does strictly less work and states the intent more clearly. The same applies to `every` versus `filter(p).length === arr.length`. ## The empty-array answers `[].some(anything)` is `false` and `[].every(anything)` is `true`. The predicate is never called in either case. The `every` result is **vacuous truth**: the claim "all elements satisfy P" can only be falsified by exhibiting an element that fails, and an empty array has none, so the claim stands. It is mathematically right and operationally dangerous. A validator such as `fields.every(f => f.valid)` reports "valid" for a form with no fields at all; a permission check such as `requiredRoles.every(r => user.roles.includes(r))` grants access when the required-roles list arrives empty because an upstream call failed. The fix is not to distrust `every`, it is to make emptiness an explicit case: ```js if (fields.length === 0) throw new Error('no fields to validate'); const ok = fields.every(f => f.valid); ``` ## Holes are skipped Unlike the `find` family, `some` and `every` check whether each index actually exists before invoking the predicate, so holes in a sparse array are skipped entirely: ```js Array(3).some(() => true); // false — the predicate never runs Array(3).every(() => false); // true — same reason Array(3).findIndex(x => x === undefined); // 0 — find visits holes ``` So `every` on an all-holes array behaves exactly like `every` on an empty one, which compounds the vacuous-truth trap when the array came from `new Array(n)` or from an assignment that raised `length`. ## Truthiness, not equality The predicate's return value is coerced to a boolean. A predicate that ends with `return item.error` treats the empty string and `0` as "no error" and any non-empty message as "error" — usually what was meant, occasionally not. When the intent is a strict test, write the comparison explicitly (`return item.error != null`) rather than relying on coercion the next reader has to reconstruct. ## Mutation during the scan The index range is fixed by the `length` read when the call starts, so elements appended by the predicate are never visited, and elements changed before their turn are seen with their new value. A predicate with side effects therefore produces results that depend on where the short-circuit lands — a genuinely non-deterministic-feeling bug. Keep predicates pure. ## Picking the right tool Use `some` for "is there any…", `every` for "are they all…", `includes` when you are comparing against a fixed value rather than running a test, and `find`/`findIndex` when you need the matching element or its position rather than a yes/no. Choosing the boolean method when a boolean is what you want keeps both the intent and the work minimal.