Pull in `sindresorhus/user-home` as `os.homedir()`

[vkurchatkin]

1. This is generally useful
2. We already have tmpdir()
3. It is required for repl history support

/cc @a8m @sindresorhus

[rvagg]

Anybody else feel like #596 is getting out of hand or am I the only one?

[cjihrig]

@vkurchatkin I'm not sure whether we should include the functionality or not, but I'm gonna throw in my own module (https://github.com/cjihrig/userinfo) for consideration. It works at the C level and doesn't rely on environment variables.

@rvagg yes. Seems like something that could live outside of core.

[a8m]

@rvagg I agree with you, but there's a reason why.
after issue-394 opened, come three different implementations: 434, 442, 596, but we're not sure what is the right way(I'm not tagging those issues because it's irrelevant here).
thanks for @vkurchatkin CR I think 596 has the best implementation(I'm trying to stay objective).

@cjihrig I'm not sure how this could live outside of core.

[vkurchatkin]

@cjihrig repl history definitely can't live outside of core

[cjihrig]

I haven't dug deeply into this, but just based on a little Googling, it does seem possible:

• https://github.com/tmpvar/repl.history
• http://stackoverflow.com/questions/18511787/is-there-a-way-to-have-node-preserve-command-line-history-between-sessions

[vkurchatkin]

We also have this: https://github.com/iojs/io.js/blob/v1.x/lib/module.js#L495

[silverwind]

Would love to see this in core (along with path.resolve("~") support, but that's another story).

If the C functions in @cjihrig's module work universally, I'd say that would be the best approach.

[rvagg]

As I mentioned before, there are existing packages that will give you fancy repl functionality outside if core, including history but also lots of other features. replpad by @thlorenz is just one example.

My contention here is that the amount of additional code burden to get this feature in to core may suggest that it probably doesn't belong here. Core should remain lean and the node philosophy has evolved strongly into "small-core, vibrant-userland" so we need to always keep that in mind when assessing what pet-feature someone wants to bundle into core.

[thlorenz]

Actually history is that one feature I didn't get to yet, but am very open to have this added.
Please submit PRs here :P.

[rvagg]

On the topic of user home detection in core I'm a strong -1 at this stage. It's not a clean operation and exposing it to users as if it were is fraught with danger.

Consider how the suggested user-home module works for instance. If $HOME is not set on a non-Windows, non-Mac platform (i.e. the most common platforms for Node deployment: Linux and other unixes) then it assumes /home/user, which is absolutely not safe even if the common case. There is a strong case that if you cannot safely detect user home then you should fail and report. For example, an application started from Upstart or systemd where $HOME is optional, NY preference would be to fail if we really need to access user home and haven't been told where it is. A transparent operation from core conveys the impression that it's safe and can be trusted, best to encourage manual detection or using a userland module which comes with all the standard caveats that userland modules come with.

[cjihrig]

I'm also -1 on any type of detection involving environment variables.

[silverwind]

@cjihrig do you know if getlogin_r() + getpwnam() works on all Unix-based OS?