An option to wait for cache.set to resolve before resolving the returned promise (or even make this the default behavior)

[futpib]

One can bypass cache by making multiple consecutive calls with the same arguments:

// Imagine a custom `cache` with a slow `cache.set` and a fast `cache.has`
await memoized('foo'); // Calls `cache.set('foo', 'bar')`
// First `cache.set('foo', 'bar')` promise did not resolve yet and `cache.has('foo')` will resolve to `false`
await memoized('foo'); // Calls `cache.set('foo', 'bar')` again
// Some time later...
// First `cache.set('foo', 'bar')` promise resolved
// Only now will `cache.has('foo')` resolve to `true`
// Second `cache.set('foo', 'bar')` promise resolved but it should not have been called in the first place

p-memoize/index.ts

Line 122 in e8574a1

cache.set(key, result);

See this PR for a test that demonstrates this #35
See this PR for a head-on fix (breaking change) that awaits all cache operations #36

[Richienb]

@sindresorhus

• If we check promiseCache for a pending call first, values that are removed from cache by external means are not picked up on.
• If we check cache first, the promiseCache becomes useless since there is already a value in cache which causes this issue. (current behaviour)

Maybe it should be made an option?

[Richienb]

Even if we did await all set calls, behold this simple example:

await Promise.all([
	memoized('foo'),
	memoized('foo'),
]);

[sindresorhus]

^ @futpib Any opinion?

It's unclear to me what the best way forward here is.

[Richienb]

@sindresorhus Solved it by caching the entire asynchronous part of the pMemoize function rather than just the promise returned by the memoized function. See #48.