-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
child_process: align fork/spawn stdio error msg #11044
Conversation
@mscdex approved? Do I need to wait 2 days, or can I revert once there are two approvals? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. However, if @mscdex's request to change the error message was the only thing outstanding, couldn't it just be updated here?
If nobody else had any questions/suggestions about the original changes, then it would probably be easier to just change the error message here instead of revert + change. |
OK, I'll revise this PR to be an update of the error message. On monday, though. Cheers. |
37692db
to
9e99195
Compare
replaced revert with code, PTAL
@mscdex I fixed the error message, PTAL, sorry I didn't understand what you LGTM was conditional on. |
doc/api/child_process.md
Outdated
@@ -299,6 +299,9 @@ output on this fd is expected to be line delimited JSON objects. | |||
*Note: Unlike the fork(2) POSIX system call, `child_process.fork()` does | |||
not clone the current process.* | |||
|
|||
*Note*: Support for non-Array values of the `.stdio` option was added in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if we want to start adding this kind of information in this way or not. I think it's probably a separate discussion to be had outside of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't we usually put something in the API docs when we make breaking API changes? I'll check around to see what we've done in the recent past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK we haven't been including version information when it comes to changes in behavior over time. That might be beneficial, but still it's a separate discussion on if we want to start doing that and if so, how something like that would be best conveyed to the end user (presumably not in a free-form way like this note).
doc/api/child_process.md
Outdated
@@ -299,6 +299,9 @@ output on this fd is expected to be line delimited JSON objects. | |||
*Note: Unlike the fork(2) POSIX system call, `child_process.fork()` does | |||
not clone the current process.* | |||
|
|||
*Note*: Support for non-Array values of the `.stdio` option was added in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@addaleax (because you did the original YAML markup, I think) @MylesBorins Will this work?
Our 'ADDED' metadata is not granular enough. It tracks API additions, mostly, but it doesn't account for backporting though 00ffa33 gives me the impression it was intended to.
Since it doesn't track changes in APIs, will this note work? Will the FIXME (EDIT: <-- I meant REPLACEME
) get processed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the FIXME (EDIT: <-- I meant
REPLACEME
) get processed?
Yup, the releaser will be warned by the build script (which does just a plain “grep”) and replace it.
Our 'ADDED' metadata is not granular enough.
Working on that! ;)
lib/child_process.js
Outdated
case 'inherit': | ||
return [option, option, option, 'ipc']; | ||
} | ||
throw new TypeError('Incorrect value of stdio option: ' + option); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should instead go inside a default:
case in the switch
above.
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily.
f76e668
to
f338521
Compare
PTAL @mscdex |
LGTM if CI is ok with it: https://ci.nodejs.org/job/node-test-pull-request/6142/ |
ci: https://ci.nodejs.org/job/node-test-pull-request/6150/ One of the freebsd machines failed a number of cluster tests. Trying again, may be ephemeral. |
The change LGTM but does this need to be semver-major? Are the error conditions changing here? It's not obvious |
Scratch that, the error message change definitely makes this semver-major |
Adding properties to options objects, so long as they are not required, is semver-minor. |
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily. PR-URL: #11044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Brian White <[email protected]>
Landed in 4cafa60 |
fork()'s support for .stdio strings in 3268863 used a different TypeError string from spawn, unnecessarily. PR-URL: nodejs#11044 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Sam Roberts <[email protected]> Reviewed-By: Brian White <[email protected]>
fork()'s support for .stdio strings in 3268863 used a different
TypeError string from spawn, unnecessarily.