Adhere to XDG Base Desktop Specification

[hyperupcall]

haii,
i was wondering if there is any interest to adhere to the xdg base desktop specification, even if it's just a little bit? right now i see a ~/.pnpm-store file created in the home directory. better adherence would mean checking for the variable $XDG_DATA_HOME, and creating the file at $XDG_DATA_HOME/pnpm-store. if $XDG_DATA_HOME is not set, then the file should be created at ~/.local/share/pnpm-store. if this is a bit too much to ask, can we set a variable like $PNPM_STORE_PATH to manually set the path? (i like my home directory, and would very much like to change the location). i read the docs and couldn't seem to find any more detail about how pnpm handles creating the .pnpm-store file. more info on the xdg base directory specification can be found here

thankies,
edwin

[zkochan]

I don't have objections. On what systems should this be the behavior? On non-windows? Or only on Linux?

If we do this, we should do this now. Before pnpm v5 is out

cc @pnpm/collaborators

[KSXGitHub]

This would break existing workflows. My CIs cache ~/.pnpm-store.

if this is a bit too much to ask, can we set a variable like $PNPM_STORE_PATH to manually set the path?

You can use --store-dir:

pnpm install --store-dir $XDG_DATA_HOME/.pnpm-store

[zkochan]

Or through the $NPM_CONFIG_STORE_DIR env variable.

[aparajita]

There are many competing standards, like ~/.config, .local/, and so on. The only way to please everyone is to make it configurable via an environment variable. Asking the user to use --store-dir every time is too prone to error.

[alexeyten]

@aparajita

There are many competing standards

They are not compete. They are part of XDG standard. https://wiki.archlinux.org/index.php/XDG_Base_Directory#User_directories

That is pnpm store should be in ~/.local/share/... ($XDG_DATA_HOME) if it’s considered essential or .cache/... ($XDG_CACHE_HOME) if one think it could be purged without harm (I don’t think so).

[KSXGitHub]

I don't consider ~/.pnpm-store a cache. There are hard links to it, disk space wouldn't be free by simply deleting it (if anything, it would only occupies even more disk space should pnpm install is invoked again).

[zkochan]

ok, so should we have this logic?

if process.platform is linux then:

1. use the value of $XDG_DATA_HOME
2. or use ~/.local/share otherwise.

[KSXGitHub]

ok, so should we have this logic?

if process.platform is linux then:

1. use the value of $XDG_DATA_HOME
2. or use ~/.local/share otherwise.

Implementing this would do more harm than good in my opinion. --store-dir and corresponding environment variable (which is the second option OP asked for) is already supported so I don't see much gain.

[zkochan]

ok, I will keep it open for further discussion but won't do it in scope of v5.

[hyperupcall]

thanks for mentioning the NPM_CONFIG_STORE_DIR environment variable - i'll use it a workaround for now since setting alises for install, uninstall, etc. to include --store-dir is a bit messy for me. is NPM_CONFIG_STORE_DIR a pnpm only thing - because i can't find any documentation about it on on the npm website?

if it's decided to go with this, i think resolution should look something like this to preserve backwards compatibility

1. use ~/.pnpm-store if ~/.pnpm-store exists
2. otherwise use $XDG_DATA_HOME/pnpm-store
3. otherwise use ~/.local/share/pnpm-store

[KSXGitHub]

if it's decided to go with this, i think resolution should look something like this to preserve backwards compatibility

1. use ~/.pnpm-store if ~/.pnpm-store exists
2. otherwise use $XDG_DATA_HOME/pnpm-store
3. otherwise use ~/.local/share/pnpm-store

This would dramatically increase complexity, not for the main code, but for the tests.

Prove that this feature worth it.

[rhendric]

There are a few other issues I've found while trying to massage pnpm into XDG-compliance:

• Is there a way to read global settings from a config file that isn't ~/.npmrc? (Ideally: $XDG_CONFIG_HOME/pnpmrc, falling back to ~/.config/pnpmrc—or npmrc in both cases I guess; I don't quite understand why pnpm tries to piggy-back on npm's config file, and those reasons may or may not be applicable if breaking with npm's config file location)
• Is there a way to relocate ~/.pnpm-state.json? (Ideally: $XDG_CACHE_HOME/pnpm-state.json, falling back to ~/.cache/pnpm-state.json—at least, I think this is a cache file.)
• Relocating the pnpm-global directory is possible with .npmrc, but: its default location is as a child of npm's prefix directory, which is inconsistent with how npm uses that variable. npm expects prefix to have bin and lib children, and so pnpm-global should logically default to $prefix/share/pnpm-global.

As for why pnpm should bother with any of this: the virtues of the XDG base directory spec are not specific to pnpm, and you can find lots of words spilled in lots of other places about why it's worth it. In short: it declutters, it enables version control of configuration, it enables different backup strategies for caches versus other local data, it enables these locations to be moved to other filesystems in unusual circumstances without fiddling with each program's configuration individually, and probably a few other common advantages that don't come immediately to mind. Separating out cache from configuration from other local user-specific files is just a user-friendly move in general, because it gives the user more power to manage those things appropriately. And having standard but configurable locations for those three types of data just makes sense so that said management can be applied across many applications.

[razor-x]

Here is the corresponding issue for Yarn: yarnpkg/yarn#2334
And npm: npm/npm#6675
And poetry: python-poetry/poetry#1239

I've noticed many projects follow this pattern:

1. Hard-code homedir() (or equivalent).
2. Project becomes popular.
3. Support XDG issue is opened.
4. Issue stays open for n-years (pretty much the same back and forth happens in each project between users and maintainers).
5. Users beg for workarounds to keep their homedir pollution under control.
6. If users are lucky XDG support is eventually added.

While we wait for for step 4 to run it's course, I recommend (plead 🙏🏻 ) swapping out all the hard-coded homedir() calls today for something like process.env.PNPM_HOME || homedir(). Then at least the users can implement their workarounds now while the maintainers decide if XDG is right for them. 😄

[flosker]

+1 for this
Please also consider - pnpm-state.json

[zkochan]

I am OK changing this in the next major version.

As of now

1. the location of the store-dir may be changed: pnpm set store-dir "~/.local/share/pnpm-store"
2. the location of the global-dir may be changed: pnpm set global-dir ~/.local/share/pnpm-global (but I am not 100% sure this will work properly as I am not sure the commands will be linked to a directory that is in the PATH)

I think we can move the pnpm-state.json file to $XDG_STATE_HOME any time. I don't think it is a breaking change.

The pnpm store currently contains also the cache of package metadata files. These files can be safely removed, so they should be stored separatly from the content-addressable store. The content-addressable store should be in $XDG_DATA_HOME. The metadata files should be at $XDG_CACHE_HOME

According to this standard, is it fine to install the actual pnpm source files at ~/.pnpm or is there some other place pnpm should be installed to?

---

Edit: probably moving the metadata cache to $XDG_CACHE_HOME is not a breaking change as well.

[hyperupcall]

The new changes sound fantastic, on the assumption that files will have a parent directory of pnpm (ex. $XDG_STATE_HOME/pnpm/pnpm-state.json) (Each application typically has their own subfolder)

According to this standard, is it fine to install the actual pnpm source files at ~/.pnpm or is there some other place pnpm should be installed to?

The way I interpret the standard, it seems the the pnpm source files should be installed to some directory in $XDG_DATA_HOME/pnpm, rather than in ~/.pnpm. Having a folder such as .pnpm in the home folder sort of defeats the point of changing the locations of other pnpm-specific cache and state files to be more XDG Base Dir compliant

[flosker]

I agree with @eankeen, It would be much better to store data in

E.g.
~/.local/share/pnpm
~/.config/pnpm
~/.cache/pnpm
...etc.

Instead of ~/.pnpm, as those are the official directory specs.

Or you can give user option to set custom paths like we already have with store-dir, etc. options. This would also prevent anything from breaking, as the user can decide to either keep old locations or set new ones.

---

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[zkochan]

Is it OK to use the XDG standard on macOS as well?

[hyperupcall]

I don't use macOS anymore, so I don't have direct experience, but I will say that it's definitely OK in my view. Adhering to the standard solves the same problems as on Linux, and will match the behavior of many programs ran on macOS - ex. saving configuration to ~/.config, rather than using the de jure macOS configuration location of ~/Library/Preferences. The latter doesn't really seem like a user-friendly location anyways, especially if it is mainly littered with plist files at the top level, rather than config segregated by subfolder. With that said, I don't think I have seen people move their program files from macOS-style (ex. ~/Library/Preferences) to XDG-style

[ghost]

XDG specifications were designed to be used in Linux, but fit other systems as well. Here is a rust lib trying to do this in bast possible way. It boils down to this:

1. Follow XDG environment variables
2. Fall back to appropriate path for platform

So, for MacOS config files should never be saved in ~/.config, unless user explicitly sets variable to do so. Scheme above is breaking for existing projects, so ideally this should be done in non-braking way as so:

1. Try old (previously hardcoded) locations
2. Try XDG environment variables
3. Try appropriate path for platform

Of course this increases complexity. It is up to maintainer if making this change non-breaking is worth the effort. Project mentioned above and this point paths that should be used as last fallback. If maintaining the code used to lookup old locations is too much, it could be retired after a transition period.

This issue is really common. It always goes just like @razor-x described. Users are tired. Please don't end up like bash, minecraft or ssh.

[zkochan]

Seems like @folder/xdg may be used to get defaults for different operating systems.

Does it make sense to install pnpm into /Users/<user>/Library/Application Support/pnpm on macOS?

[nikoladev]

@zkochan Looking into my Application Support folder it seems most apps use it for storage, caches, logs, databases, settings, user data, etc.

Don't know how it is for apps that adhere to XDG, but generally it would seem weird to install something there.

But if anyone knows macOS internals better I would go with their advice.

[zkochan]

@umireon suggested the app support folder

#3633 (comment)

[nikoladev]

I did some quick searching (by no means a thorough search). I have found that this project uses Application Support as well, but it also has other more detailed directory placements for Unix, macOS, and Windows. Might be interesting to check out.

And I found this Stack Overflow discussion where the most upvoted answer recommends ~/Library/ for XDG_DATA_HOME and also links to some macOS documentation on it.

To me it seems that implementing XDG requires a bit of research if we want to properly implement it. Maybe it can be done in parts? If it's easier to implement for Linux, we could only focus on that for now?

[umireon]

@nikoladev Really insightful.

To me it seems that implementing XDG requires a bit of research if we want to properly implement it. Maybe it can be done in parts? If it's easier to implement for Linux, we could only focus on that for now?

I as a Homebrew contributor need this on macOS very soon.

https://developer.apple.com/library/archive/qa/qa1170/_index.html

Note: The ~/Library/Application Support directory is reserved for non-essential application resources like templates or plug-ins which may be changed by the user. It should not be used to store irreplaceable user data.

I change the suggestion: I suggest ~/Library/pnpm.

[zkochan]

ok, let's do ~/Library/pnpm on macOS

[vjpr]

IntelliJ/WebStorm seems to need to manually add support to the new pnpm home dir: https://youtrack.jetbrains.com/issue/IDEA-276673

[zkochan]

Moving the config to XDG_CONFIG_HOME: #3873

[zkochan]

One last thing that wasn't changed is the location of the global store. Should we change it to $XDG_DATA_HOME/pnpm/store ? The source codes of pnpm are already in $XDG_DATA_HOME/pnpm

There was some concern regarding this:

This would break existing workflows. My CIs cache ~/.pnpm-store.

We can change the location of the global store in pnpm v7 #4522

[LeviticusMB]

Noticed the location was going to change in v7, which is great. Never liked ~/.pnpm-store. But wouldn't XDG_CACHE_HOME be more appropriate than XDG_DATA_HOME for the store?

I've always used store-dir=~/Library/Caches/pnpm in my global .npmrc myself. Which is right next to ~/Library/Caches/Yarn/ ...

[zkochan]

#2574 (comment)