.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 #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.