(If you know C# LINQ , it's like Any vs All)

• some will return true if any predicate is true

• every will return true if all predicate is true

Where predicate means function that returns bool ( true/false) for each element

every returns on first false.
some returns on first true

This is essentially a current limitation in TypeScript; see microsoft/TypeScript#44373.

TypeScript has long had a problem with calling methods on a union of array types. Originally you couldn't call unions-of-functions at all, because the compiler didn't know how to merge multiple signatures into a single usable one. See microsoft/TypeScript#7294:

// Before TS3.3:
declare const arr: string[] | number[];
arr.some(() => true); // error
arr.map(() => 1); // error
arr.every(() => true); // error

TypeScript 3.3 introduced some support for doing this with microsoft/TypeScript#29011, by accepting an intersection of the parameters from the union members.

But this support was only added for relatively simple cases where at most one member of the union was a generic function and at most one member of the union was an overloaded function. So if the array methods you were merging were generic or overloaded, you still couldn't call them. So there was an improvement, but some methods like map() still weren't callable. See microsoft/TypeScript#36390:

// TS3.3
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // okay

At some point it was decided to add a generic overload to every() so that it could act as a type guard function; see microsoft/TypeScript#38200. This is useful, but unfortunately it means that every() also stopped working on unions of array types. This was released with TypeScript 4.0:

// TS 4.0
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // error
arr.every(() => true); // error

For TypeScript 4.2 microsoft/TypeScript#31023 was merged, which added some support for calling unions of generic call signatures, as long as the generic type parameters were identical. But for overloaded call signatures, the problem persists:

// TS 4.2+
declare const arr: string[] | number[];
arr.some(() => true); // okay
arr.map(() => 1); // okay
arr.every(() => true); // error 

And that's where we are currently.

Maybe at some point, microsoft/TypeScript#44373 will be addressed. It's not obvious what the right thing to do here is for unions of overloaded methods in general. I think it's possible someone might want to target just the unions-of-array case by automatically widening to a readonly-array-of-unions, since doing that manually is the workaround I usually suggest, and it's fairly safe:

const arr2: readonly (string | number)[] = arr; // okay
arr2.every(() => true); // okay

But for now, this doesn't happen.

Playgorund link to code

If I understand your point correctly, you seem to be mis-using or abusing every and some but it's a little unavoidable if you want to change the elements of your arrays directly. Correct me if I'm wrong, but what you're trying to do is find out if some or every element in your sequence exhibits a certain condition then modify those elements. Also, your code seems to be applying something to all items until you find one that doesn't pass the predicate and I don't think that's what you mean to be doing. Anyways.

Let's take your first example (slightly modified)

if (input.every(function (that) {
    return typeof that === "number";
})) {
    input.every(function (that) {
        that.foo();
    }
} else {
    return;
}

What you're doing here actually goes a little against the spirit of the some/every/map/reduce/filter/etc concepts. Every isn't meant to be used to affect every item that conforms to something, rather it should only be used to tell you if every item in a collection does. If you want to apply a function to all items for which a predicate evaluates to true, the "good" way to do it is

var filtered = array.filter(function(item) {
    return typeof item === "number";
});

var mapped = filtered.map(function(item) {
    return item.foo(); //provided foo() has no side effects and returns a new object of item's type instead.  See note about foreach below.
});

Alternatively, you could use foreach instead of map to modify the items in-place.

The same logic applies to some, basically:

• You use every to test if all elements in an array pass some test.
• You use some to test if at least one element in an array passes some test.
• You use map to return a new array containing 1 element (which is the result of a function of your choice) for every element in an input array.
• You use filter to return an array of length 0 < length < initial array length elements, all contained in the original array and all passing the supplied predicate test.
• You use foreach if you want map but in-place
• You use reduce if you want to combine the results of an array in a single object result (which could be an array but doesn't have to).

The more you use them (and the more you write LISP code), the more you realize how they are related and how it's even possible to emulate/implement one with the others. What's powerful with these queries and what's really interesting is their semantics, and how they really push you towards eliminating harmful side-effects in your code.

EDIT (in light of comments): So let's say you want to validate that every element is an object and convert them to an Application Model if they're all valid. One way to do this in a single pass would be:

var dirty = false;
var app_domain_objects = input.map(function(item) {
    if(validate(item)) {
        return new Model(item);
    } else {
        dirty = true; //dirty is captured by the function passed to map, but you know that :)
    }
});
if(dirty) {
    //your validation test failed, do w/e you need to
} else {
    //You can use app_domain_objects
}

This way, when an object doesn't pass validation, you still keep iterating through the entire array, which would be slower than just validating with every. However, most of the time your array will be valid (or I should hope so), so in most cases you'll perform a single pass over your array and end up with a usable array of Application Model objects. Semantics will be respected, side-effects avoided and everyone will be happy!

Note that you could also write your own query, similar to foreach, which would apply a function to all members of an array and returns true/false if they all pass a predicate test. Something like:

function apply_to_every(arr, predicate, func) {
    var passed = true;
    for(var i = 0; i < array.length; ++i) {
        if(predicate(arr[i])) {
            func(arr[i]);
        } else {
            passed = false;
            break;
        }
    }
    return passed;
}

Although that would modify the array in place.

I hope this helps, it was very fun to write. Cheers!