-
Notifications
You must be signed in to change notification settings - Fork 28.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Promise-based versions for some functions in child_process #49904
Comments
I would like to see |
FTR, that already exists, it's why you can General expectation management: open a pull request if you want to see this happen. exec and execFile have util.promisify.custom hooks that can be repurposed. |
That was the intention, and I added |
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment. For more information on how the project manages feature requests, please consult the feature request management document. |
Great APIs makes devs happy, so bumping. |
I may be misunderstanding this, but doesn't |
You are misunderstanding. The functions you list are sync, not async. I think you need to read up a bit more about this in the linked documents in the original post. |
What is the problem this feature will solve?
It would be nice if child_process functionality, such as
exec
andexecFile
, had Promised based versions by default. Currently it does not, see https://nodejs.org/api/child_process.htmlNote that only child_process functions that can be async/await should be considered. This does not include things such as
fork
orspawn
.What is the feature you are proposing to solve the problem?
A new
child_process/promises
import path that can be used similar to how fs promises are used:The ask is basically that
child_process/promises
could just return a variant such asconst exec = util.promisify(process.exec);
as a convenience.What alternatives have you considered?
I am already using
const exec = util.promisify(process.exec);
but that is not as nice. And this new proposal follows along what is happening in other Node.js APIs.(The original ask in #38823 was perceived as asking for the entire module and all APIs to be async/await. This issue here narrows it down to only focus on the functions that can be.)
The text was updated successfully, but these errors were encountered: