What is the benefit of promisifying the call to Crypto.pbkdf2(...args)?

[ntaranov]

Support plan

• is this issue currently blocking your project? - yes
• is this issue affecting a production system? - no

Context

• node version: any
• module version: 5
• environment (e.g. node, browser, native): any
• used with (e.g. hapi application, another framework, standalone, ...): next-connect, express
• any other relevant information:

How can we help?

Is there any real benefit from promisifying call to Crypto.pbkdf2(...args)?

ff20b73

I have 2 points here.

1. This is a single-task library and sync vs async consumption should be left to the consumer from the design perspective, unless forcing the pattern is absolutely unavoidable. Everything can be promisified at any level without a problem if need be. I'm in the process of switching from hapi/iron to another implementation. Please provide me an example of real benefit of doing this for this CPU-bound task if I don't understand something.
2. Many frameworks call lifecycle methods without awaiting them, making APIs async effectively breaks them all - you simply cannot fire an async "fire and forget" function from sync without creating a race condition.

[Gil Pedersen]

I'm not sure why you are trying to enforce your design considerations onto this project. I suggest you take a more measured approach, if you intend to make the maintainers listen to you.

The promisifying is just another way to call into the async Crypto API. This ensures that the JS runtime does not stall while the result is computed in another CPU thread.