Yarn: .yarnrc isn't actually an rc file

[bronson]

~/.yarnrc currently contains:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
lastUpdateCheck 1490798662566

The other rc files in your home directory are meant to be edited directly. (It's fine to offer additional ways to edit the file, but direct editing should an option. Ferexample, ~/.npmrc is meant to be edited directly or with assistance from npm config)

Another difference is that rc files should only contain configuration information. lastUpdateCheck is state, and only applies to the local machine. This means that anyone who includes ~/.yarnrc in their dotfiles repo will need to resolve conflicts frequently. That's quite a few people: https://www.google.com/search?q=dotfiles+yarnrc

Potential Solution

Best would be to move the state information to a separate file (say, ~/.yarn-cache or ~/.cache/yarn). That keeps configuration and state separate, and putting ~/.yarnrc in dotfiles would work again.

If configuration information and state information must be stored in the same file, then removing the "rc" from the end of the filename would help a lot. Adding a # DO NOT COMMIT TO YOUR DOTFILES comment to the file would also reduce confusion.

First mentioned in https://github.com/yarnpkg/yarn/issues/3010

[houshuang]

Just adding that it's important to me to be able to commit the .yarnrc file with a workspaces-based repo, otherwise I'll have to tell all collaborators to manually create this yarnrc file before doing yarn install.

[BYK]

Just adding that it's important to me to be able to commit the .yarnrc file with a workspaces-based repo, otherwise I'll have to tell all collaborators to manually create this yarnrc file before doing yarn install.

You can have project-specific .yarnrc files at project root directories. This is actually already being used by projects like babel for instance: https://github.com/babel/babel/blob/7.0/.yarnrc

@bronson - I think you are onto something. That said I'm not sure how easy it is to change the location of that timestamp.

@kittens would you mind chiming in and tell us if there was a specific reason why we made this decision?

[sebmck]

The other rc files in your home directory are meant to be edited directly.

We append the AUTOGENERATED banner to all stringified lockfiles (which is the format .yarnrc uses), source code is here. That banner could be omitted for .yarnrc files when we write them though.

Another difference is that rc files should only contain configuration information. lastUpdateCheck is state, and only applies to the local machine.

I only put it there because it was the easiest way to store things like preferences since we already had the code to modify ~/.yarnrc via yarn config * so it was easiest to reuse it than mess around with more file system persistence logic.

[BYK]

@bronson what do you think about @kittens' latest message? If you can suggest a place to store that lastUpdateCheck information, we can then move it away, remove the "AUTOGENERATED DON'T TOUCH" header from the top and close this issue.

[bronson]

@BYK that sounds exactly right.

I suggest putting lastUpdateCheck into a new file named ~/.yarn-cache. And then, agreed, removing the warnings from ~/.yarnrc and closing this issue.

(edit: minor hesitation deleted. I'm fully on board)

[gpspake]

I'm finding that a .yarnrc file is created in my home directory every time I run yarn at the local project level. I need .yarnrc to be generated in a different path than ~/.yarnrc but there doesn't seem to be an environment variable to change where that file gets created :(

[djmitche]

@gpspake that sounds like a different bug

[Gudahtt]

Moving lastUpdateCheck to a cache file sounds like a reasonable solution.

If we're to go ahead with this change, we should make sure that this new cache file is saved in the conventional place (i.e. follows the XDG Base Directory Specification on Linux, and comparable Windows conventions), rather than in the home directory. Yarn already partially follows these conventions as of this PR.

[mo22]

possible temporary workaround is disabling the self-update check alltogether
disable-self-update-check true

[agnjunio]

I'm all in for moving lastUpdateCheck and all other cache stuff to a cache file.

[gabegorelick]

Not being able to check .yarnrc into source control severely limits the new policies feature since users need to update their yarn-path manually.

[sporkd]

Another problem is the hardcoded path to you home directory

e.g. prefix "/Users/peter/.yarn"

This prevents other people from easily forking your dotfiles. I am tracking all my rcfiles in git, and .yarnrc seems to be the only one that has a hardcoded path with my username it it.

[FireyFly]

I'm glad to hear the runtime state is being separated from the config file. Since we're revamping this anyway, I think it would be nice to honour XDG Base Directory environment variables when set. This allows for easy user-wide configuration of locations for things like config files, without having to set it on a per-application basis.

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

It's pretty widely recognised on *NIX (and is basically where the ~/.config etc convention stems from, which also would be used as fallbacks if the environment variables aren't set).

[wagenet]

What's the status on this? We're trying to use policies but the other cruft in the .yarnrc is problematic.

[ElijahLynn]

My use case for this is that on a firewalled network we have to add cafile <path/to/ca-bundle.crt> to the ~/.yarnrc or else yarn just hangs with no error message (took hours to figure that out, btw). This needs to be an Ansible role we can share across the entire ORG and ~ isn't always the same. We need the file to also be out of a home directory and closer to something like /etc/.yarnrc. Right now it is scary to even add it to the ~/.yarnrc file because it says it is autogenerated.

[tommedema]

Since this is such a fundamental need and the issue was raised back in 2017 I am wondering if people have come up with any workarounds to be able to commit your .yarnrc file in version control?

[texastoland]

~I just use .npmrc because Yarn reads it anyway.~ (Not working anymore #7593)

[gabegorelick]

I think this is fixed in Yarn 2 since it uses .yarnrc.yml.

[dantman]

.yarnrc.yml seems to be the future for Yarn 2 users. And for Yarn 1 users .npmrc can do some of what is needed.

However Yarn 2 has introduced a bit of an issue for Yarn 1 users. The recommendation seems to be to use policies/set-version to lock a project using Yarn 1 to a Yarn 1 version. This creates a .yarnrc file with a yarn-path config for project-specific yarn release.

Which brings us back to this issue. yarnrc contains things like email/lastUpdateCheck/username that should not be committed. But you need to commit .yarnrc in order for policies/set-version to work for a project using Yarn 1. And Yarn 2 "fixed" the yarn issue with .yarnrc.yml but that doesn't help you continue to use Yarn 1.