-
-
Notifications
You must be signed in to change notification settings - Fork 224
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
Attach .nodeChildProcess
to the execa promise
#413
Comments
Yes this sounds good 👍 |
Any thoughts on the name?
|
|
👍 |
@wesleytodd Based on your comment here, would you like to take a look at doing a PR for this feature? Please let us know if you need any help! |
I plan to, just have other priorities at work. If someone else gets to it before me that’s fine, my guess is I will be able to do it late next week at the earliest. |
Per this comment, we are going to name the property |
.child
to the execa promise.subprocess
to the execa promise
We probably should keep the following specific methods on the returned This leads a much more natural syntax. const result = await execa`npm run build`
.pipe`sort`
.pipe`head -n 2`;
for await (const line of execa`npm run build`) {
// ...
}
for await (const line of execa`npm run build`.iterable().drop(3)) {
// ...
} Instead of: const result = await execa`npm run build`
.subprocess.pipe`sort`
.subprocess.pipe`head -n 2`;
for await (const line of execa`npm run build`.subprocess) {
// ...
}
for await (const line of execa`npm run build`.subprocess.iterable().drop(3)) {
// ...
} All the other properties/methods though can be on the |
I've been thinking about this issue, and would suggest the following:
This means the return value of Execa:
The reasons of this change is:
The upsides of keeping all the Execa API at the top level (as opposed to moving them to the new
In other words, we're getting most of the benefits, but without the drawbacks. What do you think @sindresorhus? |
This generally sounds good. Except, since we don't really want users to use the ChildProcess instance, maybe make it a less convenient name like |
Yes, Also, this allows us to keep calling the top-level value So this leads to those action points:
So the main breaking changes are:
|
.subprocess
to the execa promise.nodeChildProcess
to the execa promise
We probably should do the same change that we did with
Generally speaking, not being able to use |
👍 |
Node.js does this now for
childProcess.
when you promisify it.https://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback
The name is to be decided.
One day, I hope we can get rid of
execa()
being both a childProcess and promise and just have the.child
property on the promise. But that's a huge breaking change. For now, the best we can do is to add it, and recommend new users to use it instead of the old way. We could even un-document the old way.@ehmicky Thoughts?
The text was updated successfully, but these errors were encountered: