add 'subprocess' alias to 'child_process' ?

[ry]

i've always hated the name 'child_process' but does this incur needless confusion?

[felixge]

i've always hated the name 'child_process'

+1

but does this incur needless confusion?

Not sure if 'subprocess' is much better. What about naming the module 'exec'? What's exec now, could be: exec.shell('shell command'), execFile() (currently undocumented) would just become exec.file(), and spawn would stay as exec.spawn().

Should all be doable while keeping backwards compatibility until we do hard deprecation.

[bnoordhuis]

I like felixge's suggestion.

[abi]

• 1 to exec.

[aikar]

+1 also.

everything 'native' has been pretty short and sweet without underscores, except for child_process and now string_decoder.

maybe should pick a new name for it too.

[koichik]

Can someone review koichik/node@d79a08c?

[bnoordhuis]

@koichik: There are two issues with the patch.

1. A number of files are deleted, then recreated with a new name instead of renamed - it breaks the git history.
2. Landing this patch now will cause lots of merge conflicts when merging v0.6 into master. I'd rather land it near 0.6's EOL.

[defunctzombie]

subprocess is what python calls it. What do other languages use?

[koichik]

@bnoordhuis:

1. A number of files are deleted, then recreated with a new name instead of renamed - it breaks the git history.

I used git mv for the renaming of all files, but... the Git is too difficult for me :-<

1. I'd rather land it near 0.6's EOL.

okay.

[felixge]

@koichik : Reviewed it and <3 the patch : ). But I agree with @bnoordhuis that waiting until 0.6's EOL sounds good.

[isaacs]

I've always hated "child_process" as well. Sadly, there are two problems with this proposal:

1. There is a frighteningly high likelihood that the confusion caused by the rename is greater than the benefit.
2. We cannot get away with another sys -> util shift. We must support require("child_process") forever (or, at least until node 2.0, whichever comes first.)

Given that it is too late to remove "child_process" safely, the result of this is that we'll end up with an alias, which also must be maintained forever, and will cause confusion because new users won't understand why there are two names for the same thing. And having two names is even less elegant than one, even if that one is not so elegant.

I'm going to close this. @bnoordhuis @felixge @koichik If you feel that this line of reasoning is faulty, then please reopen. We can take the discussion to the userlist to get more people weighing in on it and help judge how much chaos it'll cause. If we do end up doing this, then we'll need to do it soon. I want to be prepared to say that the list of modules in 0.8 is final.

[bnoordhuis]

If you feel that this line of reasoning is faulty

I wouldn't call it faulty but I don't see a problem with having an alias and phasing that out like we did with the sys module. There were of course people grumbling over that but that's an inescapable fact of life, they'll get over it. We should do a better job documenting NODE_DEBUG next time, though. :-)

[joaquinperaza]

Six years later, some people (or alt least myself) still think isn't a great name, you should have renamed it.

[refack]

Hello @joaquinperaza, thank you for the feedback. As you might have noticed, this is an archived repo, the active repo is at https://github.com/nodejs/node/issues/
At this time point the problem with aliasing is that subprocess is already an established modules on npm - https://www.npmjs.com/package/subprocess
What we did recently is update the documentation to use subprocess nodejs/node#14578 instead on child