.yarnrc isn’t actually an rc file

~/.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

Author: Fantashit

9 thoughts on “.yarnrc isn’t actually an rc file

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

  2. @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.

  3. @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)

  4. 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 🙁

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

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

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

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

  9. 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?

Comments are closed.