Match [].some() behavior

[fregante]

I think I see two main differences:

• count is required, while it should likely just default to 1
• [].some(() => true) just returns false while pSome([], {count:1}) will throw
• p-some is acting as a limited filter rather than a boolean-returning function

I'd suggest moving this limiting behavior to https://github.com/sindresorhus/p-filter or rethink this this pattern with the upcoming iterator helpers: https://github.com/tc39/proposal-iterator-helpers#takelimit

For example: [...promises].filter(filtererFn).take(2)

[fregante]

Note: When count === 1 and filter === undefined, the current behavior matches Promise.any exactly.

[fregante]

This is my local implementation of a boolean p-some for Refined GitHub:

export default async function pSome(iterable: Iterable<Promise<unknown>>): Promise<boolean> {
	return new Promise(resolve => {
		for (const promise of iterable) {
			(async () => {
				if (await promise) {
					resolve(true);
				}
			})();
		}

		void Promise.allSettled(iterable).then(() => {
			resolve(false);
		});
	});
}

[sindresorhus]

While the naming is unfortunately because of Array#some, is it really worth doing a big breaking change at this point? The package is stable and it will eventually be replaced by built-in methods.

Maybe do a named export for this behavior or a separate package?

[fregante]

at this point?

Before this point: 7 years
After this point: eternity

Never too late 😃

big breaking change

As long as there's an easy upgrade path I don't see the problem with it.

it will eventually be replaced by built-in methods

Are you talking about https://github.com/tc39/proposal-iterator-helpers#somefn

You may be right, it might be possible to use Iterator.from(array).some(fn)

[sindresorhus]

Before this point: 7 years

Counterpoint: No one needed what you propose in 7 years of its existence.

[sindresorhus]

As long as there's an easy upgrade path I don't see the problem with it.

What is the upgrade path? If we change from returning the values to returning a boolean, I don't really see how the user could even upgrade.

[fregante]

Counterpoint: No one needed what you propose in 7 years of its existence.

It's more likely that they settled for its booleanish equivalence and there are plenty of bugs caused by Promise<false> in the wild. Given that .some() is part of the tiny standard lib of JavaScript I'd dare to say more than "no one" needs this specific behavior.

[sindresorhus]

I only use it for the current behavior.

[sindresorhus]

Totally irrelevant, but I find the name Array#some confusing. In a proper language, it would have simply been an overload of Array#includes. It should at minimum have been named Array#hasSome. This package name is modeled after Promise.all => Promise.some. If you think about it like that, the current behavior makes more sense, it returns some elements, not all.

[fregante]

As for the modeling, it looks this matches Bluebird's .some() method exactly so I'll close this issue.

http://bluebirdjs.com/docs/api/promise.some.html