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.fork: add string-shortcut for stdio #10866

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
8 participants
@trendsetter37
Contributor

trendsetter37 commented Jan 18, 2017

Add string-shortcut option for stdio parameter.

closes #10793

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

doc, child_process

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 18, 2017

Contributor

The subsystem name should just be child_process. This should fit the first line length limit: child_process: add string shortcut for fork stdio.

Contributor

mscdex commented Jan 18, 2017

The subsystem name should just be child_process. This should fit the first line length limit: child_process: add string shortcut for fork stdio.

Show outdated Hide outdated lib/child_process.js
@@ -50,7 +50,24 @@ exports.fork = function(modulePath /*, args, options*/) {
args = execArgv.concat([modulePath], args);
if (!Array.isArray(options.stdio)) {
if (typeof options.stdio == 'string') {
const stdioStringToArray = (option) => {

This comment has been minimized.

@mscdex

mscdex Jan 18, 2017

Contributor

I think this should be moved outside of fork() since it does not rely on any variables in the current scope, where it should use the function stdioStringToArray(option) { ... } format.

@mscdex

mscdex Jan 18, 2017

Contributor

I think this should be moved outside of fork() since it does not rely on any variables in the current scope, where it should use the function stdioStringToArray(option) { ... } format.

This comment has been minimized.

@trendsetter37

trendsetter37 Jan 18, 2017

Contributor

While it doesn't depend on any variables in the fork() scope I did think it logically belonged inside of fork because it wasn't generic enough to be used by any of the other exported functions needing the stdioStringToArray operation.

Case in point, fork is the only function that requires 'ipc' be append to the returned array. This is just my opinion though so comments/feedback are welcomed.

@trendsetter37

trendsetter37 Jan 18, 2017

Contributor

While it doesn't depend on any variables in the fork() scope I did think it logically belonged inside of fork because it wasn't generic enough to be used by any of the other exported functions needing the stdioStringToArray operation.

Case in point, fork is the only function that requires 'ipc' be append to the returned array. This is just my opinion though so comments/feedback are welcomed.

This comment has been minimized.

@mscdex

mscdex Jan 18, 2017

Contributor

Well, the main idea is to avoid the possibility of V8 having to recompile/reoptimize the function. By pulling it out of the function, that can be achieved for sure.

@mscdex

mscdex Jan 18, 2017

Contributor

Well, the main idea is to avoid the possibility of V8 having to recompile/reoptimize the function. By pulling it out of the function, that can be achieved for sure.

Show outdated Hide outdated lib/child_process.js
@@ -50,7 +50,24 @@ exports.fork = function(modulePath /*, args, options*/) {
args = execArgv.concat([modulePath], args);
if (!Array.isArray(options.stdio)) {
if (typeof options.stdio == 'string') {

This comment has been minimized.

@mscdex

mscdex Jan 18, 2017

Contributor

Triple equals needed here.

@mscdex

mscdex Jan 18, 2017

Contributor

Triple equals needed here.

Show outdated Hide outdated lib/child_process.js
break;
case 'inherit':
options.stdio = stdioStringToArray(options.stdio);
break;

This comment has been minimized.

@addaleax

addaleax Jan 18, 2017

Member

fwiw it looks like you can shorten these to

case 'ignore':
case 'pipe':
case 'inherit':
    options.stdio = stdioStringToArray(options.stdio);
    break;
@addaleax

addaleax Jan 18, 2017

Member

fwiw it looks like you can shorten these to

case 'ignore':
case 'pipe':
case 'inherit':
    options.stdio = stdioStringToArray(options.stdio);
    break;

This comment has been minimized.

@trendsetter37

trendsetter37 Jan 18, 2017

Contributor

Wow, yep. Definitely missed that; thanks

@trendsetter37

trendsetter37 Jan 18, 2017

Contributor

Wow, yep. Definitely missed that; thanks

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 18, 2017

Contributor

I guess I shouldn't squash until the entire review process is done right?

Contributor

trendsetter37 commented Jan 18, 2017

I guess I shouldn't squash until the entire review process is done right?

Show outdated Hide outdated lib/child_process.js
options.stdio = stdioStringToArray(options.stdio);
break;
default:
throw new TypeError(`Incorrect type of stdio option: ${options.stdio}`);

This comment has been minimized.

@Trott

Trott Jan 18, 2017

Member

Nit: It would probably be more consistent with our other TypeError messages if this were something like Unknown stdio option: ${options.stdio}.

@Trott

Trott Jan 18, 2017

Member

Nit: It would probably be more consistent with our other TypeError messages if this were something like Unknown stdio option: ${options.stdio}.

This comment has been minimized.

@sam-github

sam-github Jan 18, 2017

Member

Should the unknown option be embedded in the message? What happens if a complex JSON object is in there? One that is circular? Won't the attempt to stringify it fail? I don't think we generaly print the bad input in the message, we just say what is bad about the input.

@sam-github

sam-github Jan 18, 2017

Member

Should the unknown option be embedded in the message? What happens if a complex JSON object is in there? One that is circular? Won't the attempt to stringify it fail? I don't think we generaly print the bad input in the message, we just say what is bad about the input.

This comment has been minimized.

@addaleax

addaleax Jan 18, 2017

Member

@sam-github grep -R 'new [A-Za-z]*Error' lib|grep '`' does give about 10 positive results or so.

Fwiw I find it really useful when I can just take part of an error message and grep my sources for that bit with a reasonable expectation of instantly finding the offending lines. If you’re worried about failed stringifying, we can always wrap the input in util.inspect; does that sound better?

@addaleax

addaleax Jan 18, 2017

Member

@sam-github grep -R 'new [A-Za-z]*Error' lib|grep '`' does give about 10 positive results or so.

Fwiw I find it really useful when I can just take part of an error message and grep my sources for that bit with a reasonable expectation of instantly finding the offending lines. If you’re worried about failed stringifying, we can always wrap the input in util.inspect; does that sound better?

This comment has been minimized.

@sam-github

sam-github Jan 18, 2017

Member

The fixed string part should be greppable and unique, as you say. Just tested, the stringification seems to just do [object Object] for recursive and complex objects. Not useful, but not damaging.

git grep TypeError lib is pretty clear: https://gist.github.com/f81b6d3e19ab6595244905575e55e082

There are many, many lines, and all the errors say WHAT is wrong with the input, but do not re-include the input itself in the message.

git grep TypeError.*\` lib       
lib/dns.js:    throw new TypeError(`"port" should be >= 0 and < 65536, got "${port}"`);
lib/internal/url.js:      throw new TypeError('Value of `this` is not a URLSearchParams');
... (all examples of `this`, not of format strings)

So at this point, we have one example of a format string inputting an invalid argument into the type error message, and this would be the second, so now I'm convinced. The error should not echo the input back, it should include information that is not known to the caller - what is wrong with the input, not the input itself.

@sam-github

sam-github Jan 18, 2017

Member

The fixed string part should be greppable and unique, as you say. Just tested, the stringification seems to just do [object Object] for recursive and complex objects. Not useful, but not damaging.

git grep TypeError lib is pretty clear: https://gist.github.com/f81b6d3e19ab6595244905575e55e082

There are many, many lines, and all the errors say WHAT is wrong with the input, but do not re-include the input itself in the message.

git grep TypeError.*\` lib       
lib/dns.js:    throw new TypeError(`"port" should be >= 0 and < 65536, got "${port}"`);
lib/internal/url.js:      throw new TypeError('Value of `this` is not a URLSearchParams');
... (all examples of `this`, not of format strings)

So at this point, we have one example of a format string inputting an invalid argument into the type error message, and this would be the second, so now I'm convinced. The error should not echo the input back, it should include information that is not known to the caller - what is wrong with the input, not the input itself.

This comment has been minimized.

@addaleax

addaleax Jan 18, 2017

Member

git grep TypeError lib

Funny, why does git (re-?)implement grep?

So at this point, we have one example of a format string inputting an invalid argument into the type error message, and this would be the second, so now I'm convinced.

These are the positive results when not restricting to TypeErrors (or is there any particular reason you only looked for those?): https://gist.github.com/addaleax/cd3d3e5a6c7d752eaa1d15396e80608e (“only” 12 but still.)

But why does it really matter whether there are precedents for this? I can’t really see any situation in which this is harmful, and I can see cases in which echoing the input back might be helpful (very simple example: typos).

@addaleax

addaleax Jan 18, 2017

Member

git grep TypeError lib

Funny, why does git (re-?)implement grep?

So at this point, we have one example of a format string inputting an invalid argument into the type error message, and this would be the second, so now I'm convinced.

These are the positive results when not restricting to TypeErrors (or is there any particular reason you only looked for those?): https://gist.github.com/addaleax/cd3d3e5a6c7d752eaa1d15396e80608e (“only” 12 but still.)

But why does it really matter whether there are precedents for this? I can’t really see any situation in which this is harmful, and I can see cases in which echoing the input back might be helpful (very simple example: typos).

This comment has been minimized.

@sam-github

sam-github Jan 18, 2017

Member

I find randomness in APIs not helpful. When one API does it one way, and another does it another way, its confusing. If we believe that errors on invalid arguments to API calls should include the input, we should then start work on adding such information to every error, would make good code-and-learn contributions. If we don't believe that, and individual errors that say "X is wrong with argument Y" (maybe followed with) ": got/was/saw/whatever ${y}" are randomly formatted according to what looked good in a single PR or appeals to the taste of whoever happend to write and review that PR, we get a chaotic API. Btw, in your gist, lines 3 and 4 should be type errors to be consistent with line 2... the type of error chosen for those is another example of the kind of random API choice I would like us to make less of.

@sam-github

sam-github Jan 18, 2017

Member

I find randomness in APIs not helpful. When one API does it one way, and another does it another way, its confusing. If we believe that errors on invalid arguments to API calls should include the input, we should then start work on adding such information to every error, would make good code-and-learn contributions. If we don't believe that, and individual errors that say "X is wrong with argument Y" (maybe followed with) ": got/was/saw/whatever ${y}" are randomly formatted according to what looked good in a single PR or appeals to the taste of whoever happend to write and review that PR, we get a chaotic API. Btw, in your gist, lines 3 and 4 should be type errors to be consistent with line 2... the type of error chosen for those is another example of the kind of random API choice I would like us to make less of.

This comment has been minimized.

@trendsetter37

trendsetter37 Jan 20, 2017

Contributor

@sam-github I opted to go with the TypeError: Unknown stdio option although I do find it useful to have the corrupted input logged back to the developer. That being said, I don't think it's useful enough to go against consistency unless we do decide that it is beneficial to change all errors accordingly.

@addaleax I did have to use util.inspect to prevent printing [Object Object]. Not sure why I forgot to use that in the original PR

@trendsetter37

trendsetter37 Jan 20, 2017

Contributor

@sam-github I opted to go with the TypeError: Unknown stdio option although I do find it useful to have the corrupted input logged back to the developer. That being said, I don't think it's useful enough to go against consistency unless we do decide that it is beneficial to change all errors accordingly.

@addaleax I did have to use util.inspect to prevent printing [Object Object]. Not sure why I forgot to use that in the original PR

Show outdated Hide outdated test/parallel/test-child-process-fork-stdio-string-variant.js
const malFormedOpts = {stdio: '33'};
const payload = {hello: 'world'};
assert.throws(() => fork(childScript, malFormedOpts), /Incorrect type/);

This comment has been minimized.

@Trott

Trott Jan 18, 2017

Member

If possible, let's match the entire error message in the regular expression, so something like ^TypeError: Unknown stdio option: 33$/ or whatever the message ends up being.

@Trott

Trott Jan 18, 2017

Member

If possible, let's match the entire error message in the regular expression, so something like ^TypeError: Unknown stdio option: 33$/ or whatever the message ends up being.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Jan 18, 2017

Member

I guess I shouldn't squash until the entire review process is done right?

Up to you, I think. In most cases, I prefer that we don't squash until the review process is done but others feel differently.

Member

Trott commented Jan 18, 2017

I guess I shouldn't squash until the entire review process is done right?

Up to you, I think. In most cases, I prefer that we don't squash until the review process is done but others feel differently.

Show outdated Hide outdated lib/child_process.js
options.stdio = stdioStringToArray(options.stdio);
break;
default:
throw new TypeError(`Incorrect type of stdio option: ${options.stdio}`);

This comment has been minimized.

@sam-github

sam-github Jan 18, 2017

Member

Should the unknown option be embedded in the message? What happens if a complex JSON object is in there? One that is circular? Won't the attempt to stringify it fail? I don't think we generaly print the bad input in the message, we just say what is bad about the input.

@sam-github

sam-github Jan 18, 2017

Member

Should the unknown option be embedded in the message? What happens if a complex JSON object is in there? One that is circular? Won't the attempt to stringify it fail? I don't think we generaly print the bad input in the message, we just say what is bad about the input.

Show outdated Hide outdated lib/child_process.js
@@ -50,7 +50,20 @@ exports.fork = function(modulePath /*, args, options*/) {
args = execArgv.concat([modulePath], args);
if (!Array.isArray(options.stdio)) {
if (typeof options.stdio === 'string') {
const stdioStringToArray = (option) => {

This comment has been minimized.

@cjihrig

cjihrig Jan 18, 2017

Contributor

You can make this a normal function, and pull it out of fork() to the top level.

@cjihrig

cjihrig Jan 18, 2017

Contributor

You can make this a normal function, and pull it out of fork() to the top level.

Show outdated Hide outdated lib/child_process.js
default:
throw new TypeError(`Incorrect type of stdio option: ${options.stdio}`);
}
} else if (!Array.isArray(options.stdio)) {
// Use a separate fd=3 for the IPC channel. Inherit stdin, stdout,
// and stderr from the parent if silent isn't set.
options.stdio = options.silent ? ['pipe', 'pipe', 'pipe', 'ipc'] :

This comment has been minimized.

@cjihrig

cjihrig Jan 18, 2017

Contributor

You can use stdioStringToArray() here too.

@cjihrig

cjihrig Jan 18, 2017

Contributor

You can use stdioStringToArray() here too.

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 20, 2017

Contributor

@cjihrig @sam-github changes commited.

Contributor

trendsetter37 commented Jan 20, 2017

@cjihrig @sam-github changes commited.

@sam-github

Re-add the link to https://nodejs.org/api/child_process.html#child_process_options_stdio, which describes the meaning of this option. We need that info.

Otherwise, LGTM

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37
Contributor

trendsetter37 commented Jan 22, 2017

@sam-github Done.

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37
Contributor

trendsetter37 commented Jan 23, 2017

Show outdated Hide outdated doc/api/child_process.md
[`stdio`][] option. When this option is provided, it overrides `silent`.
The array must contain exactly one item with value `'ipc'` or an error will
be thrown. For instance `[0, 1, 2, 'ipc']`.
* `stdio` {Array|String} Supports the Array and String versions of

This comment has been minimized.

@cjihrig

cjihrig Jan 23, 2017

Contributor

I don't think we need to explicitly say "Supports the Array and String versions of..." since they are now the same. Maybe just a note to "see child_process.spawn()'s stdio"

@cjihrig

cjihrig Jan 23, 2017

Contributor

I don't think we need to explicitly say "Supports the Array and String versions of..." since they are now the same. Maybe just a note to "see child_process.spawn()'s stdio"

Show outdated Hide outdated lib/child_process.js
@@ -455,6 +469,7 @@ function lookupSignal(signal) {
if (typeof signal === 'number')
return signal;

This comment has been minimized.

@cjihrig

cjihrig Jan 23, 2017

Contributor

Can you remove this blank line.

@cjihrig

cjihrig Jan 23, 2017

Contributor

Can you remove this blank line.

Show outdated Hide outdated test/parallel/test-child-process-fork-stdio-string-variant.js
const errorRegexp = /^TypeError: Unknown stdio option$/;
const malFormedOpts = {stdio: '33'};
const payload = {hello: 'world'};
const StringOpts = {stdio: 'pipe'};

This comment has been minimized.

@cjihrig

cjihrig Jan 23, 2017

Contributor

StringOpts -> stringOpts please

@cjihrig

cjihrig Jan 23, 2017

Contributor

StringOpts -> stringOpts please

Show outdated Hide outdated test/parallel/test-child-process-fork-stdio-string-variant.js
const child = fork(childScript, StringOpts);
child.on('message', (message) => {
assert.ok(message.foo);

This comment has been minimized.

@cjihrig

cjihrig Jan 23, 2017

Contributor

Is there a strictEqual() comparison that you can make here?

@cjihrig

cjihrig Jan 23, 2017

Contributor

Is there a strictEqual() comparison that you can make here?

@cjihrig

Left a few comments. Looking good though.

Show outdated Hide outdated test/parallel/test-child-process-fork-stdio-string-variant.js
const child = fork(childScript, stringOpts);
child.on('message', (message) => {
assert.deepStrictEqual({foo: 'bar'}, message);

This comment has been minimized.

@cjihrig

cjihrig Jan 24, 2017

Contributor

Can you change the order of the arguments (actual, expected).

@cjihrig

cjihrig Jan 24, 2017

Contributor

Can you change the order of the arguments (actual, expected).

This comment has been minimized.

@trendsetter37

trendsetter37 Jan 24, 2017

Contributor

Sure thing

@trendsetter37

trendsetter37 Jan 24, 2017

Contributor

Sure thing

@cjihrig

LGTM with one nit.

@trendsetter37

Squash approved changes /cc @lib/child_process

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 25, 2017

Contributor

@cjihrig @sam-github It looks like test/arm is failing all over the place in Jenkins. Is that something I need to address?

Contributor

trendsetter37 commented Jan 25, 2017

@cjihrig @sam-github It looks like test/arm is failing all over the place in Jenkins. Is that something I need to address?

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 25, 2017

Member

Its just broken, known, you don't have to address.

Member

sam-github commented Jan 25, 2017

Its just broken, known, you don't have to address.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 25, 2017

Member

@addaleax @mscdex want to give a final thumbs up?

Member

sam-github commented Jan 25, 2017

@addaleax @mscdex want to give a final thumbs up?

options.stdio = stdioStringToArray(options.stdio);
break;
default:
throw new TypeError('Unknown stdio option');

This comment has been minimized.

@mscdex

mscdex Jan 25, 2017

Contributor

I think we should use the same error string used by _validateStdio() which is used by spawn().

@mscdex

mscdex Jan 25, 2017

Contributor

I think we should use the same error string used by _validateStdio() which is used by spawn().

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 25, 2017

Contributor

Also, I think Fixes: ... should be used instead in the commit message.

Contributor

mscdex commented Jan 25, 2017

Also, I think Fixes: ... should be used instead in the commit message.

@addaleax

I do still think @mscdex’ request is a good idea (i.e. going back to including the option in the error message) but this LGTM either way.

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 25, 2017

Contributor

@mscdex so Fix: stdio string shortcut instead of child_process: add stdio string shortcut? Or are you referring to the message body and not the top line?

Technically it wasn't a fix because the docs mentioned that it only supported the array version. So this PR added the string feature to provide consistency between fork and spawn.

Contributor

trendsetter37 commented Jan 25, 2017

@mscdex so Fix: stdio string shortcut instead of child_process: add stdio string shortcut? Or are you referring to the message body and not the top line?

Technically it wasn't a fix because the docs mentioned that it only supported the array version. So this PR added the string feature to provide consistency between fork and spawn.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 25, 2017

Contributor

@trendsetter37 I was referring to the line that references the issue.

Contributor

mscdex commented Jan 25, 2017

@trendsetter37 I was referring to the line that references the issue.

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 26, 2017

Contributor

@mscdex ohh ok, I see

Edit: Done.

Contributor

trendsetter37 commented Jan 26, 2017

@mscdex ohh ok, I see

Edit: Done.

child_process: add string shortcut for fork stdio
Add string shortcut option for stdio parameter.

PR-URL: #10866
Fixes: #10793
@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 26, 2017

Contributor

@trendsetter37 Other than the error message text, it LGTM.

Contributor

mscdex commented Jan 26, 2017

@trendsetter37 Other than the error message text, it LGTM.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 27, 2017

Member

Landed in 3268863, thanks.

Member

sam-github commented Jan 27, 2017

Landed in 3268863, thanks.

@sam-github sam-github closed this Jan 27, 2017

sam-github added a commit that referenced this pull request Jan 27, 2017

child_process: add string shortcut for fork stdio
Add string shortcut option for stdio parameter.

Fixes: #10793
PR-URL: #10866
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Brian White <mscdex@mscdex.net>
@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 27, 2017

Contributor

@sam-github My LGTM was conditional, I was wanting the error text to be changed first ...

Contributor

mscdex commented Jan 27, 2017

@sam-github My LGTM was conditional, I was wanting the error text to be changed first ...

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jan 27, 2017

Member

I am also wondering if this shouldn't be semver-major due to the change in throw conditions it introduces.

Member

jasnell commented Jan 27, 2017

I am also wondering if this shouldn't be semver-major due to the change in throw conditions it introduces.

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 27, 2017

Member

Sorry, Brian, I misunderstood. And I can't figure out exactly what you want changed, I thought it was the fixes line. @mscdex Can you point me to your comment? I can fix and PR a follow up.

@jasnell probably. That the conditions under which errors are thrown and the error message strings are part of the API should be mentioned in #7964

Member

sam-github commented Jan 27, 2017

Sorry, Brian, I misunderstood. And I can't figure out exactly what you want changed, I thought it was the fixes line. @mscdex Can you point me to your comment? I can fix and PR a follow up.

@jasnell probably. That the conditions under which errors are thrown and the error message strings are part of the API should be mentioned in #7964

@sam-github sam-github referenced this pull request Jan 27, 2017

Closed

meta: deprecation policy #7964

2 of 2 tasks complete
@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 27, 2017

Member

Its probably possible to create a backportable version of this that does not throw. Or even a version that doesn't throw, and then a tiny update PR following on, that makes it throw and will only go in 8.x?

Should this be reverted and given more time?

Member

sam-github commented Jan 27, 2017

Its probably possible to create a backportable version of this that does not throw. Or even a version that doesn't throw, and then a tiny update PR following on, that makes it throw and will only go in 8.x?

Should this be reverted and given more time?

@mscdex

This comment has been minimized.

Show comment
Hide comment
Contributor

mscdex commented Jan 27, 2017

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 27, 2017

Member

What about the error message text would you like changed?

Member

sam-github commented Jan 27, 2017

What about the error message text would you like changed?

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Jan 27, 2017

Contributor

@sam-github In my first linked comment I suggested the same error message used for spawn() for the same situation.

Contributor

mscdex commented Jan 27, 2017

@sam-github In my first linked comment I suggested the same error message used for spawn() for the same situation.

@sam-github

This comment has been minimized.

Show comment
Hide comment
Member

sam-github commented Jan 27, 2017

@sam-github sam-github reopened this Jan 27, 2017

@trendsetter37

This comment has been minimized.

Show comment
Hide comment
@trendsetter37

trendsetter37 Jan 28, 2017

Contributor

@sam-github saw this just now. Should I change this here or just let the change happen on #11044?

Contributor

trendsetter37 commented Jan 28, 2017

@sam-github saw this just now. Should I change this here or just let the change happen on #11044?

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github
Member

sam-github commented Jan 30, 2017

@trendsetter37 I am fixing in #11044

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Jan 30, 2017

Member

@nodejs/lts This is a marginal case of semver-majorness. Strings were previously undefined as options.stdio values for fork(), and were ignored. Now, they are processed.

If someone is passing a string to .stdio, hoping it does something like spawn, it now will, of if they are pasing invalid values to .stdio, it will now throw.

I guess this could be major... but its also a useful feature that would be nice to have on LTS.

Is LTS just out of luck?

Member

sam-github commented Jan 30, 2017

@nodejs/lts This is a marginal case of semver-majorness. Strings were previously undefined as options.stdio values for fork(), and were ignored. Now, they are processed.

If someone is passing a string to .stdio, hoping it does something like spawn, it now will, of if they are pasing invalid values to .stdio, it will now throw.

I guess this could be major... but its also a useful feature that would be nice to have on LTS.

Is LTS just out of luck?

@trendsetter37 trendsetter37 deleted the trendsetter37:feature/10793-add-string-variant-stdio-option branch Jan 31, 2017

@Trott Trott referenced this pull request Mar 14, 2017

Closed

test: include all stdio strings for fork() #11783

2 of 2 tasks complete

@jasnell jasnell referenced this pull request Apr 4, 2017

Closed

8.0.0 Release Proposal #12220

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment