Yarn: XDG compliance

[Conaclos]

Hi :)

I noted that Yarn doesn't fit the XDG basedir specification.
It could be nice to support it.

What is the current behavior?

Currently Yarn creates its own data / cache / config directories:

• $HOME/.yarn
• $HOME/.yarn-cache
• $HOME/.yarn-config

What is the expected behavior?

Next the desired replacement (or fallback) of each directory.

• $HOME/.yarn: ${XDG_DATA_HOME:-$HOME/.local/share}/yarn
• $HOME/.yarn-cache: ${XDG_CACHE_HOME:-$HOME/.cache}/yarn
• $HOME/.yarn-config: ${XDG_CONFIG_HOME:-$HOME/.config}/yarn

OS: Linux

[jleclanche]

@kevinburke @bestander So there was an attempt at fixing this back in April, but it got abandoned.

Any chance we could get a proper plan of what needs to be done to fix this?

Qt has an excellent cross-platform reference implementation of "standard paths" in QStandardPaths: https://doc.qt.io/qt-5/qstandardpaths.html - I don't know if this exists for node, but I know it's come up in other places as well (eg. https://github.com/serverless/serverless/issues/4602)

[bestander]

If someone opens a new PR based on https://github.com/yarnpkg/yarn/pull/3674 ping me I'll merge it

[severen]

This seems to be _partially_ fixed by #5336, at least on Yarn 1.9.4. However there's still $HOME/.yarn (which appears to only contain the bin folder) and $HOME/.yarnrc, despite there also being $XDG_CONFIG_HOME/yarn (with the contents debatably being configuration), $XDG_DATA_HOME/yarn (which seems to overlap with $XDG_CONFIG_HOME/yarn...?), and $XDG_CACHE_HOME/yarn (which seems to be the only one that is properly and correctly used). This is even worse than not supporting it at all, as it's now just inconsistent and confusing.

It would be very nice if everything would be moved to follow the XDG spec. Ideally .yarnrc would be $XDG_CONFIG_HOME/yarn/config. As for $HOME/.yarn/bin, that is a bit more complicated, as the spec doesn't define a location for user-installed binaries, although $HOME/.local/bin is commonly used, which lines up with the default for $XDG_DATA_HOME ($HOME/.local/share). Hopefully one day the spec will be amended to include something like $XDG_BIN_HOME. However I believe the best solution _for now_ is to place executables in $XDG_DATA_HOME/yarn/bin and provide an environment variable to customise that location (for example, YARN_BIN_DIR).

I _may_ be able to work on this provided I can find my way around the codebase. Making sure my home directory is completely clean and not littered with a thousand random dotfiles is the dream after all.

[Siilwyn]

Is this free to pick up? I'm thinking of fixing this, I've already done this for other projects like electron-download, js-v8flags, greenkeeper and node-gyp. But I worry about having to be backward compatible, looking at the current logic it can get pretty messy.

Is it possible to make this a major change? Then I would be more than happy to fix this, using env-paths it will be pretty straightforward. @bestander

[Gudahtt]

Dropping support for the old config locations seems fine to me, as long as the migration path is painless.

This wouldn't be the only change waiting for a major version bump - see the next-major label on open PRs.

There is an open PR relating to this though - #5343. There was talk in the PR about waiting for a major version bump. I'm not sure how close that PR brings us to full XDG compliance.

[Siilwyn]

@Gudahtt thanks for your reply & good to hear. If we do migration it is not a major version bump, what do you envision as migration path?

Moving the old location files to the new locations is risky since conflicts can happen and it can break other tools using the old paths. Instead I would suggest to check the old locations but use the new locations when nothing exists on the old. But again, both solutions do not require a major version bump.

Also seeing https://github.com/yarnpkg/yarn/pull/5343#issuecomment-367730189 this looks like what I just described with an added warning. Still this PR does all the implementation itself, using a module feels more appropriate.

[Gudahtt]

Sorry, I didn't explain myself very well. I meant to say that dropping support seems fine, as long as the migration is painless and it coincides with a major version bump. A major version bump is likely in the near future, so that isn't a huge problem.

Even if we make it a breaking change, we should provide a way to migrate users from the old to the new locations. The approach discussed in that PR seems reasonable to me.

Would you mind reviewing that PR? I'd be interested to know how it lines up with what you had in mind. I would prefer that we accept that PR, but perhaps you could take over if they don't have time to finish the work.

[RX14]

Most applications that add XDG support don't change the config file location, they support both. So they check if ~/.yarnrc exists, if not use the XDG dirs. This means new installs use XDG and don't clutter home, while old installs see no breaking change.

[Siilwyn]

Haha, nice coincidence @RX14! Check my comment on the PR: https://github.com/yarnpkg/yarn/pull/5343#issuecomment-428239895

[Siilwyn]

@arcanis with no activity at the PR or in this issue can I pick this up by creating a new PR? If so: do you agree with my idea at https://github.com/yarnpkg/yarn/pull/5343#issuecomment-428239895?

[soredake]

any progress?

[charlie39]

Make it read environment variables at least. So it can be manually configured ,work on XDG compliance can continue meanwhile

[felixsanz]

bump

[gaving]

👀