Take advantage of util.promisify() if it lands in Node.js

[sindresorhus]

Just opening this so I don't forget. util.promisify() can interact directly with the V8 API, so it doesn't create closures and will be faster than userland implementations.

nodejs/node#12442

[addaleax]

@sindresorhus Don’t forget to benchmark, though. ;) I think the real advantage of util.promisify will be that Node core can specify custom implementations that use the promise directly (at least at some point in the future), instead of just wrapping the callback version.

I’ve tried some ad-hoc benchmarking, and the current way util.promisify is implemented doesn’t actually seem to perform very differently from the naïve way to wrap callback-taking functions.

[malixsys]

nodejs/node@99da8e8

[hanford]

It landed today 🎉

[mikaturk]

using pify until Node 8 LTS :)
damn LTS schedules :(
can't even use async functions, have to compile :(

[fregante]

1. pify sounds like a ponyfill for util.promisify; as such:

   Ponyfills should never use the native API, even if available
   Source: ponyfill.com

2. As Use native promisify utility when possible #49 said, catching edge cases and differences between the two APIs may not be worth the effort.

3. Doesn't util.promisify effectively replace pify? Why use pify at all if util.promisify is available?

[pi0]

@sindresorhus I've proposed #68 to use native Util.promisify when possible. Which is also published as a temporary npm package pify-native for those who wish to test it at production before this merge.

@addaleax I've implemented a benchmark suite to see how perf differs. But results shows that pify's approach currently is faster. (Wondering if i made a proper benchmark script 🤔). /cc @jdalton

[sindresorhus]

I have decided not to do this: #68 (comment)