Hi @TooTallNate -- submitting this PR because we ran into problems when contextify ran node-gyp rebuild during the installation of jsdom in our Jenkins CI setup. I'm not sure that I've covered all the bases, but am happy to update with any fixes if there's something missing.

Thanks!

@TooTallNate, please merge this PR with your suggested change

@TooTallNate I completely forgot about this PR until @dantran commented about making your suggested change. I have updated the code to use devdir instead of dev-dir. Let me know if there is anything else that should change. Thanks!

A reminder/vote for this PR. Is it OK to merge?

Very useful concept, but can we name it more meaningfully (we also have nodedir) ? This is really a cache for the node configuration and include files, so something with node and cache would be better: cachenodeinc maybe?

The default for XDG_CACHE_HOME is $HOME/.cache, so to truly follow the XDG basedir spec, that should be used if XDG_CACHE_HOME isn't set (and before HOME)

I'll also point out that under the XDG dir, the node-gyp dir ought to be node-gyp, not .node-gyp.

So I think the directory priority ought to be:

1. $XDG_CACHE_HOME/node-gyp
2. $HOME/.cache/node-gyp
3. $HOME/.node-gyp
4. $USERPROFILE/.node-gyp

Making devDir configurable seems reasonable to me but I'm less convinced that honoring XDG_CACHE_HOME is a good thing. For one, the way it's done in this PR would force everyone to download tarballs again (because the cache directory changes) when it's released.

I agree with @saper that the name is not great. Something like --cachedir better describes what it does.

Also, it would be good to have a regression test or two.

For one, the way it's done in this PR would force everyone to download tarballs again (because the cache directory changes) when it's released.

That's a valid reason against the way this PR is written, but I don't think it's necessarily a strike against XDG_CACHE_HOME in principle.

An option is to choose the directory based on which one exists and not by which env var is set (in the order I listed). This would prevent re-downloading everything. And it would allow a manual (one-time) opt-in for users to just move their ~/.node-gyp dir into the XDG location if desired.

If none of the directories already exist, then choose (and create) the directory based on the env vars.

What I missed in the discussion in #21 is why following XDG_CACHE_HOME and XDG in general is a good thing.

XDG is not a thing on Windows - people will instead use set npm_config_cachedir=c:\temp or whatever we end up naming the flag - so I'm leaning towards simply not bothering and being consistent across platforms.

There may not be XDG_* env vars on windows, but the default XDG cache dir is $HOME/.cache so using $HOME/.cache/node-gyp would be perfectly consistent across platforms. And leveraging the XDG env vars puts node-gyp in line with a host of other tools that let users manage their directory structure through the XDG env vars.

Put simply, if we agree that allowing users to configure where the node-gyp dir is (and I think that's evident with the assumption that cachedir is a useful option), then it logically follows that adhering to a spec that makes it possible for users to configure directory locations across a large and growing number of apps with just a couple env vars is vastly superior to app-specific flags/config.

Okay, I would suggest that @glosee starts with just the --cachedir option and then you or @glosee can follow up with a XDG compatibility PR. I haven't made up my mind yet about whether said compatibility is preferable but that doesn't need to hold up the core functionality.

sounds good

On Mon, Feb 8, 2016 at 9:15 AM, Ben Noordhuis [email protected]
wrote:

Okay, I would suggest that @glosee https://github.com/glosee starts
with just the --cachedir option and then you or @glosee
https://github.com/glosee can follow up with a XDG compatibility PR. I
haven't made up my mind yet about whether said compatibility is preferable
but that doesn't need to hold up the core functionality.

—
Reply to this email directly or view it on GitHub
#540 (comment).

Closing, superseded by #916 which landed earlier today.

Is there a reason why it seems that #916 declined to go with:

1. dev-dir flag
2. XDG_CACHE_HOME
3. fall back to $HOME?

I saw some discussion about Windows but that doesn't seem like a good reason to ignore the Unix platform's XDG preferences, for those who went through the trouble of setting the environment variable.

UPDATE: looks like per this comment this may be handled in a later PR

Is there an easy way for me to make use of the --dev-dir flag, as just a user of node?