hello and thank you for the PR!
How does this fix the issue? How was this tested? In the reference you mentioned, they say

To work around this, use a cache key that includes the platform you are running the job on. For example:

node-v1-{{ .Branch }}-{{ checksum "package-lock.json" }}
Can become:

node-v1-{{ arch }}-{{ .Branch }}-{{ checksum "package-lock.json" }}

but we were already using the arch before...

Also, I believe Environment.CACHE_VERSION should be kept there, it does not make any harm, does it?

Environment.CACHE_VERSION needed to be manually updated every time CI ran in order for it to be used. This solves the issue by removing that, and replacing it following the docs. I didn't add arch, I added .Branch to differentiate the caches.

This was tested on my own repository after trying to get this orb to work -- unfortunately, it's private. Please let me know of a good way for me to test it and have it reflect here.

Thanks for the PR @gretzky, however, I don't quite understand how this will fix the issue.

You've mentioned before that to workaround the issue, you are changing the value of CACHE_VERSION. This has the effect of changing the cache key that is used, and will therefore essentially clear the cache for the next run. If the cache is not restoring correctly, this makes sense why this would workaround the issue.

This PR removes that part of the cache key, and replaces it with the branch name. What I don't understand is how this will workaround the issue?

Assuming that the cache stops working after every use of the cache key (I don't think it's quite that bad, but let's assume that for now). On the first successful run the cache key will now be something like yarn-cache-macos-master-123456789-qwerty. Now if a new commit is pushed to master which does not affect the checksum hashes (ie. package.json and yarn.lock do not change), then the cache key will still be yarn-cache-macos-master-123456789-qwerty.

If the workaround is to change the cache key to essentially clear the cache, then I don't see how this PR helps with that. If anything, it makes the workaround of changing CACHE_VERSION impossible.

Can you explain a bit more about how this change either works around, or fixes, the issue at #66?

Hi people!
Just to revive this topic and understand if I can help somehow we move forward with this PR.
I have read the CircleCI Cache Documentation and in this topic it says that if we use static value to compose the cache key name, we will need to bump it manually to force a cache invalidation. That's pretty much our problem here which is solved by this PR.
About the addition of the {{ .Branch }} variable is important so we can separate the cache per Branch. This is good for us if, for example, we are adding a new package or updating a new one, so we does not break any other parallel jobs running.
What do you think? It makes sense now? Can we move forward with it?
I don't have write permission to fix the conflicts on this branch, but if I can get it I can help if you want :)

Upfront, it should be noted that what is being cached is the Yarn cache. It is not caching the node_modules folder directly. Each run of this command will start without a node_modules folder and will not be restored directly by a CircleCI cache. Instead, it caches and restores the cache that Yarn can then use when you run yarn install for it to populate the node_modules folder.

Sharing the yarn cache between branches is not an issue. Your development machine does this all the time unless you're manually clearing the cache before each yarn install on a new branch with yarn cache clean (which I imagine you aren't doing). Therefore, the branch name should not be needed in the yarn cache key as you actually want the cache to be shared across all branches. Otherwise, every PR would start with yarn deeding to download all dependences from scratch and the cache would basically never be used, at which point we may as well just remove it completely.

As you said, CircleCI recommends having a "static value" that is in the cache key to allow you to manually force an invalidation. This is exactly what the {{ .Environment.CACHE_VERSION }} part of the cache key is for, which the PR incorrectly removed.

Overall, I don't believe that this PR actually fixes the issue from #66. @vonovak suggested that #59 might be the root cause of the issue, so maybe someone could look into if that is actually the cause and if so submit a PR that fixes it.

Closing this for now as the fix does not seem correct, but please do let us know if there's a compelling reason to move forward with this.