npm-config should follow XDG directory spec for per-user config filepath

[jasonkarns]

The XDG directory spec outlines a standard, user-configurable set of directories defined as environment variables (with defaults).

npm-config should be using $XDG_CONFIG_HOME/npm/config as its config file instead of ~/.npmrc

reference spec

[jasonkarns]

related to #6561 I guess?

[rlidwka]

and the same issue is with npm cache I think

[jasonkarns]

for the time being, I've added export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/config to my bashrc, which allowed me to move ~/.npmrc to $XDG_CONFIG_HOME/npm/config.

And in my npm config, I added cache=${XDG_CACHE_HOME}/npm so I was able to remove ~/.npm (and it now stores the npm cache under $XDG_CACHE_HOME/npm)

[atbussma]

I'm not sure this is related to #6561. However your comment has helped me work around my issue by using NPM_CONFIG_USERCONFIG. Thanks.

[sindresorhus]

I have a module for this, if useful: https://github.com/sindresorhus/xdg-basedir

[mattiasb]

Yes please, I always found it weird that npm (which is relatively new software) didn't use XDG_*-dirs by standard. Even git does this since some years back.

[geophree]

I just set up cache with an env var (NPM_CONFIG_CACHE), the curly brackets in npmrc were causing:
Error: Failed to replace env in config: ${XDG_CACHE_HOME}

[akiva]

+1 Agreed. I would thoroughly enjoy seeing this implemented.

[sandys]

+1 - this needs to be consistent.

[jleclanche]

The following should happen:

• Default config file should be read from ${XDG_CONFIG_HOME:$HOME/.config}/npm/npmrc, with a fallback to ~/.npmrc (which would then be deprecated)
• Default cache directory should be changed to ${XDG_CACHE_HOME:$HOME/.cache}/npm.
• Default installation prefix should be changed to ${XDG_DATA_HOME:$HOME/.local}.

All three items are independent and don't have to be done all at the same time. If a dev greenlights this change, I'd be happy to help a patch get through.

[tomjakubowski]

Default cache directory should be changed to ${XDG_CACHE_HOME:$HOME/.cache}/npm.

This would invalidate everyone's cache (and leave a vestigal .npm directory in its wake). There should be a plan to migrate .npm to the new default location without doing that.

[jleclanche]

Why is invalidating cache an issue? It's cache. If someone wants to keep their cache they can move it themselves; I assume there would be a warning about it.

[sandys]

I would say priority ordering is also a good way to work - if a
configuration exists at legacy location, keep using it...otherwise work
with the new XDG path.
On Feb 21, 2016 05:01, "Jerome Leclanche" notifications@github.com wrote:

Why is invalidating cache an issue? It's cache. If someone wants to keep
their cache they can move it themselves; I assume there would be a warning
about it.

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

[jasonkarns]

Similar to nodejs/node-gyp#540 (comment)

I agree with @jleclanche that invalidating the cache should not be an issue. By definition, anything in a cache can (and should) be fungible. However, from a UX perspective, it would be a nicer transition if the legacy cache path is used if it exists. If it does not exist, then use ${XDG_CACHE_HOME:$HOME/.cache}/npm. This would allow those who care to move or remove the legacy cache, and immediately get the XDG-compliant behavior. Then, at some future time (probably in a major release), the legacy path shortcut can be removed (optionally with some deprecation warning period).

[othiym23]

The npm CLI is a cross-platform tool, and uses defaults and locations that are more or less platform-neutral (with some small deviance for Windows to make for a more pleasant user experience for Windows users). Also, where npm looks for those things is configurable, and there’s a global configuration file (itself configurable via environment variables) that contains that configuration. Therefore, it’s completely within the control of end users and system administrators where npm puts its configuration and cache.

Because XDG isn’t a specification intended for use by OS X or Windows, and is adopted (or not adopted) by individual distributions, if you want npm to store its data in a specific location on a class of machines, rather than just your own (in which case there’s nothing stopping you from setting up the aforementioned configuration), the appropriate thing to do is request, from the individual distributions, that they include the desired configuration when they package npm for use with that distribution. I don’t think this is something that it’s appropriate for npm to decide.

As such, I’m going to close this feature request, with the hope that the links I’ve provided will help those who want to set things up in a way that makes sense to them now have the tools to do so, and to lobby their distribution maintainers to do the same. Thanks to all for their time!

[akiva]

@othiym23 I feel this is a very odd way of looking at the request: many, many cross-platform applications implement the standard, when applicable. See: https://wiki.archlinux.org/index.php/XDG_Base_Directory_support for some such examples (by no means exhaustive). The point is to not force an expected location upon users who may choose to implement the spec on their systems. If they are not using it, you simply fall back to the current approach. This, to me, makes more sense, than to ask those users to find their own solutions, such as creating symlinks on their own.

[sandys]

chrome, libreoffice and vlc are also cross platform and honor XDG
standards.

On Sep 29, 2016 11:35 AM, "Akiva Levy" notifications@github.com wrote:

@othiym23 https://github.com/othiym23 I feel this is a very odd way of
looking at the request: many, many cross-platform applications implement
the standard, when applicable. See: https://wiki.archlinux.org/
index.php/XDG_Base_Directory_support for some such examples (by no means
exhaustive). The point is to not force an expected location upon users who
may choose to implement the spec on their systems. If they are not using
it, you simply fall back to the current approach. This, to me, makes more
sense, than to ask those users to find their own solutions, such as
creating symlinks on their own.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6675 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEsUxdMiZ-UtwEfH6_Iy2Q_DfMki02iks5qu1UTgaJpZM4C5PoA
.

[arty-name]

@othiym23 will the configuration allow package maintainers to implement a fallback to previous paths? I could not find a way to do so. Without that fallback, no distribution will implement that change: all its users will have to manually copy the configs to the new location.

[jasonkarns]

I also agree that viewing XDG as non-cross platform is rather odd. Indeed, the ~ home directory itself doesn't truly exist on Windows but %userprofile% is pretty much unanimously used in its place. npm is already using %userprofile% as HOME. And the XDG_CONFIG_HOME variable is itself reliant on $HOME, so I see no reason why the default wouldn't just be %userprofile%/.config/npm/

[HaleTom]

FYI, here is my .bashrc configuration on Ubuntu:

# XDG - set defaults as they may not be set (eg Ubuntu 14.04 LTS)
# See https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
# and https://wiki.archlinux.org/index.php/XDG_Base_Directory_support
export XDG_CONFIG_HOME="$HOME/.config"
export XDG_DATA_HOME="$HOME/.local/share"
export XDG_CACHE_HOME="$HOME/.cache"
if [ ! -w ${XDG_RUNTIME_DIR:="/run/user/$UID"} ]; then
    echo "\$XDG_RUNTIME_DIR ($XDG_RUNTIME_DIR) not writable. Setting to /tmp." >&2
    XDG_RUNTIME_DIR=/tmp
fi
export XDG_RUNTIME_DIR

# npm
# see npm config ls -l | grep /
export NPM_CONFIG_USERCONFIG=$XDG_CONFIG_HOME/npm/config
export NPM_CONFIG_CACHE=$XDG_CACHE_HOME/npm
export NPM_CONFIG_TMP=$XDG_RUNTIME_DIR/npm

[jcrben]

@othiym23 so you're basically going with a path which conflicts with the desires of all the users who have expressed an interest?

if someone went through the trouble of setting XDG_CONFIG_HOME, I don't see why it's important for npm to ignore the preference expressed by setting that environment variable

[felixsanz]

@othiym23

The npm CLI is a cross-platform tool, and uses defaults and locations that are more or less platform-neutral (with some small deviance for Windows to make for a more pleasant user experience for Windows users).

Linux users don't deserve a "more pleasant user experience" ? What the hell?

You're clearly not a Linux user and you don't give a s***, don't you?

[jasonkarns]

$HOME exists on all platforms, therefore XDG-* directories are platform neutral:

$HOME/.local/share
$HOME/.config

The fact that the XDG group itself is Linux specific doesn't make the xdg directories linux specific.

[felixsanz]

It won't break, the fallback exists because of that. It doesn't hurt to support the XDG spec, many of us will benefit. Chrome and many others support it so it's not a blocking thing.

…

On May 23, 2017 15:50, "Jason Karns" ***@***.***> wrote: $HOME exists on all platforms, therefore XDG-* directories are platform neutral: $HOME/.local/share $HOME/.config The fact that the XDG group itself is Linux specific doesn't make the xdg directories linux specific. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6675 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF5U08_hV9QK8bjxzGCOYDthIXRfue6Jks5r8uQ_gaJpZM4C5PoA> .