p-map

hands the mapper the wrong when the input is promises that settle out of order. The index is meant to be the element's position in the source (the way does it), but it ends up numbered in the order the promises happen to resolve. returns the right indices for the same input. The reason is that runs as an argument to , so it's evaluated after : Workers are spawned in source order, but each one suspends on until its promise settles, so the shared counter gets read in settlement order instead. avoids this by capturing the index when it pulls the item off the iterator, before awaiting it. The fix is to do the same here — grab the index at spawn time: Only the index the mapper sees changes; output ordering, concurrency, backpressure, and are all untouched. I also added a test with out-of-order-settling promises that asserts the index follows source order (it fails before this change and passes after).

Closes #34. What gitgot did This is an AI-drafted first pass at the issue, generated inside a sandboxed working copy by gitgot. Treat it as a starting point — pull the branch and iterate locally if needed. Commit: Iterate View this request in gitgot to access the live sandbox shell, review the agent's prompt, and request revisions: 01468a9d-aace-4653-be3e-24668c22db94 Draft PR opened by gitgot. Mark ready for review once you've verified the change.*

Many times I need a delay between function execution, for example to do fetch request and not spam kill a server. Currently proposed solution in https://github.com/sindresorhus/p-map/issues/25 is not optimal: This has some flaws: also adds a delay after last function execution needs some kind of index check to prevent ^ duplicate delay/native timeout import instead of convenient option Would be awesome to have a convenient option 😊