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. serverless/serverless#4602)

[bestander]

If someone opens a new PR based on #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 #5343 (comment) 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: #5343 (comment)

[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 #5343 (comment)?

[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]

👀

[jedahan]

It seems 1.22 supports XDG? 2d454b5

[adamroyjones]

I'm still finding that .yarn and .yarnrc files are being created in my home directory.

[melvio]

I have the same behavior as shown in @adamroyjones screenshot with yarn version 1.22.10

[rocka]

seems yarn is creating ~/.yarnrc every time when you run yarn install:

yarn/src/cli/commands/install.js

Lines 1105 to 1107 in 3119382

	this.config.registries.yarn.saveHomeConfig({
	lastUpdateCheck: Date.now(),
	});

what saveHomeConfig does is:

yarn/src/registries/yarn-registry.js

Line 139 in 3119382

await fs.writeFilePreservingEol(this.homeConfigLoc, `${stringify(this.homeConfig)}\n`);

where homeConfigLoc is hardcoded:

yarn/src/registries/yarn-registry.js

Line 56 in 3119382

this.homeConfigLoc = path.join(userHome, '.yarnrc');

it should find possible config dir like #5336 , or at least try more locations like npm-registry does.

yarn/src/registries/npm-registry.js

Lines 253 to 293 in 3119382

	async getPossibleConfigLocations(filename: string, reporter: Reporter): Promise<Array<[boolean, string, string]>> {
	let possibles = [];
	for (const rcFile of this.extraneousRcFiles.slice().reverse()) {
	possibles.push([false, path.resolve(process.cwd(), rcFile)]);
	}
	if (this.enableDefaultRc) {
	// npmrc --> ./.npmrc, ~/.npmrc, ${prefix}/etc/npmrc
	const localfile = '.' + filename;
	possibles = possibles.concat([
	[false, path.join(this.cwd, localfile)],
	[true, this.config.userconfig || path.join(userHome, localfile)],
	[false, path.join(getGlobalPrefix(), 'etc', filename)],
	]);
	// When home directory for global install is different from where $HOME/npmrc is stored,
	// E.g. /usr/local/share vs /root on linux machines, check the additional location
	if (home !== userHome) {
	possibles.push([true, path.join(home, localfile)]);
	}
	// npmrc --> ../.npmrc, ../../.npmrc, etc.
	const foldersFromRootToCwd = getPosixPath(this.cwd).split('/');
	while (foldersFromRootToCwd.length > 1) {
	possibles.push([false, path.join(foldersFromRootToCwd.join(path.sep), localfile)]);
	foldersFromRootToCwd.pop();
	}
	}
	const actuals = [];
	for (const [isHome, loc] of possibles) {
	reporter.verbose(reporter.lang('configPossibleFile', loc));
	if (await fs.exists(loc)) {
	reporter.verbose(reporter.lang('configFileFound', loc));
	actuals.push([isHome, loc, await fs.readFile(loc)]);
	}
	}
	return actuals;
	}

[guvra]

Side note: currently it seems like it's not possible to set a custom path for .yarnrc folder inside a container that runs with the nobody user (no home dir).

In the php world, composer solves this issue with a special environment variable (COMPOSER_HOME).